Why Gjallar is a "bad" Magma example (was Re: Great News - Pharo Support - Now Seaside.)

[Chris Muller]

Thanks for the note Göran, I've been racked with curiosity myself
about all the comments saying Gjaller "should not be used as an
example of how to use Magma.."

But I am not much clearer about the why.  Gjaller uses a common OO
design-pattern, Command, so why is it a "bad example" of how to use
(an ODBMS like) Magma?

Perhaps the real rumour is that it (Gjaller) is not a good example of
how to integrate Magma with Seaside?  If so, I'd like to hear more
about the "why" of that..  Can you or someone just summarize what's
being done, so we can all analyze and talk about it before we judge
whether its "good" or "bad"?

You said:

> This means Gjallar has both a traditional Magma domain model AND an endless
> collection of "delta" objects that describe each and every change that has
> been made to the model.

and this says, to me, that Magma should actually be fitting Gjaller
like a glove, because most frameworks _either_ do well with large
collections (i.e., RDBMS) but poorly with traditional object models
(mapping), OR, they do well with traditional object models (ODBMS) but
not as good with large-collections (BTree, RcBag, etc.).  Magma has
applied itself heavily to both problems.

What version of Magma are you running?  As for performance, Magma came
a long way in performance department in r41 and r42.  If you still
have performance "problems" in r42 then I'm _really_ curious to see
the stats report from a troubled client session as well as the server.
 If you:

  myMagmaSession statistics report

for the client, or, you can alternatively print it to any stream (if,
for example the printString limit can sometimes be hit with these
reports):

  myMagmaSession statistics printReportTo: someStream

and post it up here (or send me private e-mail if it's too sensitive)
it would reveal a lot about the _nature_ of Gjallers usage of Magma
and potential problem areas..

If you are running an HA (which provides more scale, but necessarily
more speed for individual clients), then please be sure to get stats
from _both_ the primary and secondary:

  myMagmaSession serverStatisticsPrimary report

and

  myMagmaSession serverStatisticsSecondary report

Regards,
  Chris


2009/8/24 Göran Krampe <goran at krampe.se>:
> Hi!
>
> Timothy James Ziebart wrote:
>>
>> 4. Are there other implementation options - sample code?  I understand the
>> Gjallar implementation is not recommended - true?
>
> If the question is - should I look at Gjallar for general information on how
> to use Magma (regardless of Seaside actually) then the answer is no. :)
>
> But sure, if you take the time to understand *why* this is so, then there
> may be interesting bits in there still.
>
> Gjallar uses the "Command pattern" extensively which means that all
> modifications to the object model are done by instantiating a certain
> "Transaction" class, feeding it with all state desribing the change to be
> made, creating a Magma transaction, telling this object to "apply" itself,
> add that object to a never ending MagmaCollection and finally committing.
>
> This means Gjallar has both a traditional Magma domain model AND an endless
> collection of "delta" objects that describe each and every change that has
> been made to the model.
>
> The reason was originally to support an offline mode, which still exists,
> but no user of Gjallar has yet actually made use of that mode.
>
> regards, Göran
>
> PS. Gjallar will soon move to latest Magma, and hopefully gain performance
> from that. We are also probably going to test other means of persistence
> during the autumn. Magma is great and cool, but we do have some performance
> problems in Gjallar and while I can't say 100% for sure it is all Magma
> related we will profile and experiment.
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>