[Cosmo-dev] 0.6 sharing proposal

[Phillip J. Eby]

At 12:06 PM 11/7/2006 -0800, Brian Moseley wrote:
>On 11/7/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>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.
>
>i don't know what you mean specifically by "object database", but we
>use hibernate to map our object model to a relational database.

In the simplest possible terms, you have implemented your own object 
database if it's not possible for someone unfamiliar with your project to 
reverse-engineer the application's outward functionality without reference 
to *anything* but the database schema.

So, if your "object model" is such that the database schema doesn't reflect 
the nature of your application, then you have a double-layered mapping of 
the type that has caused problems for Chandler and for other projects I've 
worked on.

I haven't looked at Cosmo's current code or schema, so I don't know if this 
description applies or not; some of the things mentioned in our sharing 
format meetings, however, suggested that this might be the case for Cosmo 
in the past, if not still in the present.  It's certainly still an issue 
for Chandler.


>our challenges are 1) add concepts like stamping and tags to our
>object model; 2) map them to the database to preserve performant
>queries and efficient storage; 3) make our object model as natural as
>possible for our apps and protocols to work with.

All three are almost ridiculously easy as long as you don't stick a middle 
layer (other than Hibernate) between the application domain model and the 
database.  But if you can't look in the database and see the application 
there, you're going to have performance issues in even the best case, and 
concepts like stamping likely won't fit well into an OODB paradigm, even 
though they are trivial to implement relationally.