[Chandler-dev] Big recurrence checkin

Jeffrey Harris jeffrey at osafoundation.org
Mon Nov 27 15:37:21 PST 2006

Hi Folks,

I just checked in r12430, which makes some pretty significant changes
you'll probably be noticing Real Soon Now.  Sorry to make such a big
checkin, I tried to think of a good way to split things up but I
couldn't come up with anything coherent.

>From a coding perspective, the big change is that the nonRecurringNotes
collection (which lives in the pim package) now includes modifications,
not just masters.  Please continue to only add or remove recurrence
masters to collections, this will now have the side effect of changing
collection membership for all associated modifications.

The other big change is that pretty much everything is Chandler is
slower, because we're creating many (sometimes hundreds) of "Done"
modifications.  On the up side, creating 700 modifications all at once
took so long I got sucked into trying to figure out why it was so slow
(yay, Andi fixed a repository bug as a result).  But it seemed damaging
to developer mental health to make the functional tests take forever, so
I've updated the dates on many of the functional tests to reflect this
(temporary) reality.

Sharing old recurring events has slowed down especially, because we
naively serialize each occurrence in the past, because their triage
status change is a modification.  I wouldn't recommend dogfooding from
the trunk with many recurring events until this changes.

Some of the performance hit is in new observers tracking changes, which
is hard to avoid, but most of the pain should be short term.

Once we start tracking per-attribute modifications (which is something
Grant's been working on), we'll move to a model of "un-modifying" items
whose only modification is that they've been marked done, we'll just
display the most recent Done occurrence.  This will also make it easy
for the iCalendar export code to ignore modifications that only involve
triage status (sharing recurring triage status isn't yet working, that's
bug 7496, so there's no point in serializing triage status related


More information about the chandler-dev mailing list