Cosmo 0.6.1 Model Changes

The goal of Cosmo 0.6.1 is to fully support Chandler 0.7a5 synchronization using morse code. To do this, Cosmo needs two important model changes:

Items in Multiple Collections

Currently Item has a many-to-one relationship with CollectionItem, meaning that an item can only belong to one collection. Cosmo 0.6.1 will support items in multiple collections.

Model Changes

The model changes needed to support items in multiple collections are:

• change CollectionItem Item.getParent() to Set<CollectionItem> getParents()
• map getParents() as a many-to-many association in Hibernate

Schema Changes

The db schema changes needed to support items in multiple collections are:

• parentid is removed from item table
• item_collection table is added to map many-to-many association between item and collection

Cosmo Changes

The following Cosmo code changes are required:

• Update all code using Item.getParent() to deal with multiple parents. This might get tricky when dealing with DAV as I'm not sure how DAV is going to handle multiple parents.
• Update StandardContentService^? locking algorithm to deal with items in multiple collections.
• Add DAO/service methods for adding/removing item to a collection.

Performance Impact

Performance will be impacted a little as now an extra join is required to determine an item's parents and children.

Open Issues

• Collection deletion: should all items in a collection be deleted when a colleciton is deleted? This is how it works in Cosmo 0.6. What happens when an item is in multiple collections?
• Collection Locking: I guess we have to lock all collections when updating an item.
• Removing an item from a collection is now possible(item is not deleted), need to figure out how morse code will utilize this, and how morse code syncing will handle this.

Migration Issues

The migration tasks are:

• create item_collection table
• create row in item_collection table for each row in item table that has a non-null parentid
• remove parentid in item table

Estimates

Task	Estimate
model/mapping changes	1 day
existing code changes	3 days
migration	1 day

Model Event Modifications as Separate Items

Currently Cosmo stores all event modification data in the icalendar object in EventStamp. This is different from Chandler, which models event modifications as separate Items. In order to support morse code syncing with Chandler, Cosmo needs to do the same.

Model Changes

• add NoteItem NoteItem.getModifies()
• add Set<NoteItem> NoteItem.getModifications()

NoteItem will have two new associations: one that represents the note that a note modifies and one that represents the set of notes that modify a note. In practice, a note will only have one or none of these associations. That is, a note that modifies a note will not have modifications and vice-versa.

When a NoteItem is deleted, all of its modifications will be deleted.

• create new stamp, EventModificationStamp to be placed on NoteItem modifications
• EventModificationStamp has a VEvent representing the event modification
• EventStamp.getCalendar() returns Calendar that includes master event (stored in EventStamp ) and all event modifications (stored in modification stamps). Note that this means getCalendar() will have to traverse the master item's modifications to assemble a Calendar that includes the event exceptions.

So for an .ics file that includes a master event and two event overrides (modifications), the following Cosmo objects are created:

NoteItem	Stamp	Modifies	Modifications
master	EventStamp	null	[overrideA, overrideB]
overrideA	EventModificationStamp	master	null
overrideB	EventModificationStamp	master	null

Schema Changes

The db schema changes needed to support event modifications are:

• add modifies column to item table (links item to master item)

Cosmo Changes

This change means that operating on a single event could translate into operating on multiple items in Cosmo.

For example:

CalDAV PUT
For new events, Cosmo has to parse .ics and create an item for the master event and items for each event override included in the .ics. For updates to existing events, Cosmo has to parse the .ics and updat the master EventStamp, and then has to synchronize existing modifications with what is present in the .ics file. This requires matching recurrenceIds in the .ics with existing modification items and updating them, removing any modification items that aren't present in the .ics, and adding new modification items, stamps, for new recurrenceIds. Compare this to the old way of just storing the .ics. What a pain!

Cosmo UI
Currently the Cosmo UI (RPCService) deals with single NoteItem and EventStamp and gets/updates the event using getCalenddar()/setCalendar() on EventStamp. In order to prevent too much refactoring in this code, we should provide apis such as:

updateEvent(NoteItem master, Calendar calendar)

that will take care of synchronizing a Calendar object with a master NoteItem and its modifications.

This means that caldav and cosmo ui shouldn't have to deal with modification items for the time being. Instead, they can continue to use the master event item along with the new apis.

Morse Code
Morse code will have to deal with the modification items because it has to handle eimml updates that only apply to the modification item (updated triageStatus for example).

Event Indexing
Event indexing takes place when an item with an event stamp is created/updated. This has to change because an update to an event modification now requires the event's indexes to be updated. Indexing occurs in the DAO. So lets consider a new event with two modifications:

1. item created for master
2. item created for modA
3. item created for modB

Indexing should occur after all items have been updated. For this to happen, the indexing has to be moved from the DAO layer to the service layer. This is good, because it really shouldn't be in the DAO layer.

Performance Impact

Performance for events with modifications will be impacted a lot by this changed. Instead of operating on a single item/stamp Cosmo could end up issuing a bunch of extra queries depending on the number of modifications in an event. Overall impact will depend on mix of events with and without modifications.

Migration Issues

The migration tasks are:

• add modifies column to item table
• parse out all events from event_stamp and break out modifications as separate items (this is a big task)

Estimates

Task	Estimate
model/mapping changes	1 day
service/dao changes	3 days
existing code changes	3 days
migration	5 days

-- RandyLetness - 08 Feb 2007