[Cosmo-dev] 0.6 sharing proposal
randy at osafoundation.org
Wed Nov 1 19:42:32 PST 2006
Brian Moseley wrote:
> On 11/1/06, Randy Letness <randy at osafoundation.org> wrote:
>> What about EIM records that can't be associated with an item, like
>> association records? The fact that you can have these types of EIM
>> records drove me away from storing EIM records as item attributes.
> add a new table to store these. we can do the minimum possible work
> for these, just enough to be able to regurgitate them for sync
> requests, because cosmo itself is not going to have to understand any
> semantics for these things (at least i can't think of any data types
> that we have considered building support for in the next year that fit
> this description).
Then we have things stored in multiple locations, and have to deal with
syncing them...i don't know, seems painful. I'll think about it some more.
>> Also, it turns out synchronizing individual EIM records is a lot harder
>> using Item attributes.
> how so?
I guess its similar if we can store everything as an attribute, but if
we have to store records in multiple places, it gets complicated. We
would also need a way of identifying an item attribute as an eim
record. Maybe we could create an EIMAttribute type.
> strawman: add "properties" and parameters" tables, each with name,
> value and order columns. items can have 0..* properties. properties
> can have 0..* parameters. now we have enough information to
> reconstitute the icalendar object that was originally given to us.
> hell, we can probably get rid of the calendar index table and query
> against these two instead. and we can certainly convert "item" eim
> record types to/from this structure.
Yeah we could do this, but we are talking about a lot of work. And
icalendar has no constraints on lengths of things, so we would either
have to truncate large values or store everything as a text field in the
db, which slows things down when searching (some db's don't even support
searching text fields). And 3 levels of tables (components, properties,
params) would result in some nasty queries.
>> Yes but do we want to support the nice synchronization method that only
>> sends changes to individual EIM records? This is where it gets
> it's nice to have but not necessary. if a sync only includes the
> records for changed items, that's a huge win in and of itself. we can
> look at doing record-level diffs in the future.
Yeah I hadn't thought about record-level diffs yet. That is another can
of worms as you would have to keep track of all changes to a record
instead of just the action (add/delete/modify).
More information about the cosmo-dev