At 06:09 PM 7/25/2006 -0700, Bryan Stearns wrote:
There are a couple of things happening that are calling our
attribute-redirection strategy into question...
- Bug 6387 (sorted index doesn't maintain sort) where we're trying to
index a redirectTo attribute. I'm not sure what exactly is happening, but
I can imagine: existing attribute redirection doesn't let the repository
know when a redirect-source attribute has changed, so that it can update a
redirect-target index.
Just as an FYI, we currently have about 35 "redirectTo" attributes. Of
these, 10 are redirecting to "displayName" -- and 9 times out of 10 it's a
redirection from "about" to "displayName".
This suggests to me that we don't need displayName or redirection in any of
those cases; we should just have an "about" attribute on ContentItem and
let people set it as they will.
Nearly all the remaining redirectTo attributes serve to implement "who" and
"date". Again, this seems to suggest that simply having standard "who" and
"date" attributes is a good idea, leaving it up to subclasses to set any
alternate values.
I might be wrong, but it seems to me that if we abolished the
"about->displayName" redirects and *reversed* the direction of the others,
this would solve any indexing problems with the standard who/about/date
attributes.
- The dashboard spec calls for more-complex multi-attribute sorting on
some columns; some of the sorts call for collection indexes that will need
to consider attributes on items other than the one in the collection: eg,
when sorting the date column, an item needs to produce "the next
interesting datetime", which could be the startTime if it's an event, or
the datetime of the next tickler that's going to fire (and while the spec
only calls for one tickler per item for now, there'll be multiple ticklers
in the future).
I don't have a solution to this (in spite of what John said in bug 6387),
but I'm writing this to start a conversation. Jeffrey had suggested using
onValueChanged methods to keep new just-for-indexing attributes updated.
I've suggested this also, as it should support highly dynamic use
cases. Kind of a STASCTAP solution ("simple things are simple, complex
things are possible").
Andi suggested using some form of bequeathTo (the inverse of redirectTo?),
If I understand correctly, we should just be able to reverse the direction
we're doing the redirects in. Just give every ContentItem a who, date, and
about attribute, then index those. Let subclasses worry about how to get
stuff in there. In the simple case, they can define their alternate names
(e.g. contactName, createdOn, etc.) as redirects to the base class attributes.
There is some overlap, I suspect, between all of this and
stamping. Presumably what values end up in the fields may be
state-dependent on the active stamps, so it may require an extension to the
new stamping protocol to allow delegating this computation to the
stamps. Annotations can have properties or __setattr__ hooks, so they can
easily detect when a stamp value is changed and update the main
who/date/about fields.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
