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

[Göran Krampe]

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