[Cosmo-dev] 0.6 sharing proposal

Brian Moseley bcm at osafoundation.org
Mon Nov 6 17:21:55 PST 2006


On 11/1/06, Randy Letness <randy at osafoundation.org> wrote:

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

not sure what you meant by multiple locations. records we can
associate with items get applied to those items; records we can't
associate with items get dumped into a bucket so we can spit them back
out, but we don't do anything else with them.

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

i really hope not. i think we should work towards a core object and
data model that is eim-unaware.

> Yeah we could do this, but we are talking about a lot of work.

really? maybe i'm spoiled by how fast you did the original hibernate 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).

i'm curious what the chandler repository's policy is on this. i'd be
okay with truncation, or even with rejecting values that are too big.

> And 3 levels of tables (components, properties,
> params) would result in some nasty queries.

nasty in terms of query formulation or performance?

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

chandler repository already does this, and i'm pretty sure we'll have
to do it someday.

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.


More information about the cosmo-dev mailing list