[Cosmo-dev] 0.6 sharing proposal

[Phillip J. Eby]

At 09:12 AM 11/7/2006 -0800, Randy Letness wrote:
>>i really hope not. i think we should work towards a core object and
>>data model that is eim-unaware.
>Yes I agree.  EIM should only be used by the sharing protocol.

EIM is just a simplified relational model, so you'll actually also be using 
a variant form of it for your storage, albeit perhaps in a less-normalized 
manner.  :)


>>overall, i think it would make sense to do a thorough examination of
>>the chandler domain model and repository to see what we can learn from
>>them. it may be that our domain model needs to start to look more like
>>chandler's in order to cope with all this new stuff.
>Yep, but one thing we need to keep in mind is that Chandler is for the 
>most part a single user app, so they can do some crazy abstract stuff and 
>not have to worry too much about performance whereas Cosmo needs to 
>potentially support thousands of users.

And the solution to both apps' problems is probably similar: move to a more 
efficient relational model for those operations that relational databases 
excel at.  :)

Mostly, however, I'd say that Chandler's domain model and repository are 
examples of what *not* to do to get maximum performance, and if I 
understand correctly, the same issues occurred in Cosmo.  That is, creating 
a database on top of a database is like implementing a JVM in Java: not so 
good, performance-wise.  :)

In Chandler's case the repository is an OODB (with all the 
query/performance problems and schema evolution problems that the term 
implies), layered on top of an ISAM database (Berkeley DB, with all the 
quirks and massive logfiles that *that* implies).  In Cosmo's case, I 
gather the layers were different in specifics, but similar in spirit.

The key lessons learned, at least from my POV are:

1. Don't implement one kind of database on top of another database; map 
your domain model directly to a database.

2. Don't try to do transparent object persistence or an object database; 
always have an explicit mapping layer (e.g. Hibernate, EIM, etc.) from your 
domain model to a pure-data model...  which is to say a relational one.

Actually, for me these are also lessons learned from painful history on a 
number of other projects as well.  Anyway, in short:

OODB is dead (and has been for some time); long live ORM!