[Cosmo-dev] Re: conference call followup

Brian Moseley bcm at osafoundation.org
Wed Jul 26 09:40:21 PDT 2006

On 7/26/06, rletness at simdeskcorp.com <rletness at simdeskcorp.com> wrote:

> 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.

yea, sounds fine.

> 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.

gotcha. and with the way the sharing discussions are going,
collections might not wind up being that interesting in and of
themselves. they might not even have uuids, for instance. so sure,
let's treat them the same as regular items for now.

> 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.

right. cool.

> 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.

that's fine, but i do want to stay away from explicit uri attributes
on items and collections, instead going with uuid and (optional) name.
that way we can always directly address the item, and we can compose a
uri for the item in higher layers by combining its name with the uri
we have composed for its parent item.

More information about the cosmo-dev mailing list