Hi Folks,
Andi and I have chatted a bit about how to get reasonable performance
and coherent indexes after a timezone change.
I think the best idea so far is to go ahead and accept a re-index hit
after every timezone change. We can keep a collection of all floating
(in this case by floating I mean floating/allDay/anyTime events) events
and reindex only those events.
This will still scale linearly with the number of floating events, but
if users tend to have a few thousand events per year, it seems likely
only a few hundred will be floating. I'm leery of features whose
performance degrades as O(n), but I'm not seeing a way to avoid that here.
We might decide in the future to implement some kind of
archiving/partitioning system for old events that avoids reindexing
older events, on the assumption that you don't really care what timezone
three year old birthdays are expressed in. I don't know exactly how
this would work, I'm just supplying a little hand waving to suggest we
might escape from O(n) with future cleverness.
We can also improve re-indexing performance for floating events by
changing effectiveStartTime from being a calculated property to being a
persisted attribute that's updated via monitors or onValueChanged. This
would allow us to use a ValueIndex instead of a CompareIndex for event
sorting, a ValueIndex avoids loading items when reindexing, it just
loads attributes.
Anyone have concerns or objections to this plan?
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
