Hi Folks, 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: ** Sort items by contact ** The relevant contact could be To: or From: if the item is an email. - 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 issues. - 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 attributes? - 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? Sincerely, Jeffre _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
