[Cosmo-dev] 0.6 sharing proposal
Phillip J. Eby
pje at telecommunity.com
Tue Nov 7 11:48:53 PST 2006
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
>>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!
More information about the cosmo-dev