Why Gjallar is a "bad" Magma example (was Re: Great News - Pharo
Support - Now Seaside.)
Göran Krampe
goran at krampe.se
Wed Aug 26 07:21:18 UTC 2009
Hi!
Chris Muller wrote:
> 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?
Well, it would not be "typical" at least. "Bad" might have been an odd
word. Let's say someone wants to learn how to use Magma, then they start
reading the code in Gjallar and get quite confused about the seemingly
huge amount of work being made just in order to change a silly field in
an object.
A BlablaTxn class is instantiated, it gets fed some things, a Magma
transaction is started, the txn object is sent #apply, yadda yadda. To a
newbie that just wants to learn how "easy" it is to use an OODB like
Magma it would look horrible.
> 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..
Besides the fact that we have implemented our own Session pool (first we
used a hacked one from Kilaua, then Keith changed it even more IIRC,
then recently I reimplemented a new pool using queues instead to make it
simpler and more robust - might be worth adopting into Magma, although I
think I read you have one of your own now too) I don't think we do odd
things regarding Seasde/Magma.
Earlier we played around a bit with sharing a readonly Magma session
between Seaside sessions but we dropped that quite a while back when
Keith managed to get some decent speed using read strategies.
> 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"?
I can do this but I really need more time and I need to look at the code
to "remember" the details :)
> 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.
Sure, I don't think I said Magma was a bad fit - I just meant that for
any Magma/Seaside newbie that wants to build a "regular" Seaside/Magma
app Gjallar displays some oddities that is not really representable -
due especially to the "Command pattern" being used 100% for all db
modifications.
> What version of Magma are you running? As for performance, Magma came
> a long way in performance department in r41 and r42.
Yeah, we need to upgrade to the latest, we are using r42Alpha4 right now.
> 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.
I will try to do that when I get back to Gjallar hacking. We have a
customer that is complaining about the performance issues so I *will*
need to look into this in the coming months anyway.
And I am also investigating alternative db solutions, perhaps mostly
because I am interested in the subject - and of course, we really need
better performance in Gjallar and while I can't say for sure that Magma
is the culprit I need to have something to compare with. :) The top
candidate that I am playing with right now is MongoDB. CouchDB doesn't
fit Gjallar very well (poor dynamic query abilities) and TC/TT is too
bare bones for Gjallar (and no community).
Another aspect is that we have experienced "odd problems" here and there
and it makes me nervous for larger deployments. For example, indexing
getting "messed up" (I really would like an ability to rebuild them
easily) makeing query results "wrong". The "magic" of Magma is also a
problem when something odd happens. It can be quite hard to know what to
do to fix it.
Here is a short story explaining what I mean with this last bit:
I am helping a customer right now with building a system in C#. They
used NHibernate+MSSQL and they got sick of hunting down problems they
just couldn't understand. There was simply too much "magic" going on
that wasn't stable enough or predictable enough.
I then helped them to move to CouchDB by implementing a C# binding for
CouchDB. Sure, the persistence needs a bit more work, but it is not as
complex as ORM mapping and above all - it is highly predictable and very
little magic going on. And the db has a nice web GUI builtin so that I
can directly inspect it and see what the hell I just put in there.
---
Anyway, I don't think we will ever stop having Magma as a db option in
Gjallar - the "all Squeak" aspect is worth a lot and alternate db
options will never offer the same degree of transparency that
Magma/Gemstone offers. And our meta model is quite complex and would
require lots of work in a non transparent db.
My opinion though is that if we can house multiple db options in the
same Gjallar codebase - then that can never be a bad thing. Thus, the
port to Gemstone seemed to be able to coexist nicely with Magma.
Anyway, I would like to end this long post by saying that I love OODBs
and I love that Squeak has one of the most advanced open source OODB
that I know of. I am amazed at ýour effort here
regards, Göran
More information about the Magma
mailing list