[Cosmo-dev] Re: conference call followup

[rletness at simdeskcorp.com]

Brian Moseley wrote:

> i've used int and date types in jcr as well. whatever hibernate has
> builtin support for - using that support gives us a simple mapping to
> the java types in our model classes.
>
> i wonder if we should explicitly address content types like event and
> calendar in the schema. we certainly have to be able to fulfill
> queries like "find all events in this calendar that occur in this time
> range" and "find the event in this calendar with this uid" as well as
> "list all items in this collection".

I was thinking for the first go-around we could implement this like the 
current calendar-flattener does, just storing all the ics properties as 
attributes.  We could and should think about storing events in the schema.

> also, should an item's "collection-ness" also be explicit in the
> model? i think maybe so. a collection will have child items, but a
> regular item won't. a collection will also have slightly different
> "built in" properties than a regular item (see the cnd for the
> existing repository schema).

We thought about that.  In the proposed schema, you can differentiate a 
collection by a specific "type".  Both collections and items need to be 
able to have arbitrary attributes associated with them.  So if you break 
out the collections, you need separate tables for collection attributes 
and item attributes.

>> The plan is to decide on a db schema, generate hibernate mapping
>> files/classes, and then dao interfaces/hibernate implementations.  We
>> are thinking that there also needs to be a set of application objects
>> defined that map to the hibernate classes to decouple the hibernate
>> model from the app.
>
>
> can you be more specific about what you mean by that last sentence?
> why wouldn't we want to use the hibernate model objects directly? 

An example is exposing a Calendar and Event object in the api, but a 
Calendar object is composed from collection and item hibernate objects.
Plus you have to be careful when exposing hibernate objects directly, 
especially in instances of lazy loading.  If you try to access something 
that hasn't been loaded, and you aren't in a session, nasty things happen.

It looks like there is a lot of discussion going on the sharing front 
that would have an impact on how data is stored.  I think we should move 
forward with a hibernate persistence layer that solves the functionality 
that Cosmo needs to provide now(think dav-centric), and then revisit 
things when the "morse code" is defined.  That way we can start plugging 
away at this sooner rather than later.

-Randy