[Dev] Index issues
bkirsch at osafoundation.org
Tue Jan 24 12:09:28 PST 2006
>** Sort items by contact **
>The relevant contact could be To: or From: if the item is an email.
One issue to remember, if we are sorting on the name of the user i.e. Brian Kirsch <bkirsch at osafoundation.org> then the sort order will need to be localized with PyICU. If we are
only using the email address bkirsch at osafoundation.org then no localized sorting is required at least
until internationalized domain names become widely used.
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
Jeffrey Harris wrote:
>This is a set of questions/issues about indexing that came up in the
>dashboard design meeting today.
>Quick background: Indexes on collections are used to
>A) avoid loading all the items in a collection when a subset of those
>items is needed, and
>B) provide fast run-time ordering to items in a collection
>Here are a few use cases we're looking at for sorting and the dashboard:
>- What happens if I get married and change my last name from Harris to
>Xanadu? I'm the same contact, but my messages need to be indexed
>differently. My understanding of re-indexing is that it won't fire when
>an attribute-of-an-attribute changes.
>** Sort items by date **
>Which date is being referenced is a complicated heuristic, involving
>reminder time, Kind, start time, email send time, and the current time.
>Alec and I discussed how to make this work for a while this afternoon.
>If the referenced date will change at some point in the future, we
>thought the existing reminder mechanism could be expanded to create an
>"reindex item" reminder.
>That helps with overtaken-by-time re-indexing, but there are a few more
>- This calculated date value will be dependent on a bunch of different
>attributes, in the case of reminder time, like for the sorting of
>contacts, an attribute-of-an-attribute. Does it work (from a
>scalability perspective) to have an index be based on a wide variety of
>- On what collection should this index live? In general I think we want
>to aim for fewer indexes on larger collections, then when ordering on a
>subset is needed, use a containing collection's index. I wonder if
>collection APIs could make this process easier?
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>Open Source Applications Foundation "Dev" mailing list
More information about the Dev