Thanks, John... I was hoping to find a solution that avoided changes
across multiple layers of our architecture (especially since
everything's being rearchitected now anyway, and since I got flack from
specialized use of indexing in the past)... I don't think a previous
version of an index would work, either, since it might contain a
different collection of items from the current collection.
D John Anderson wrote:
Perhaps the repository could postpone updating a particular index,
instead logging the changes which might get played back later to update
the index. As you point out, however, we'd have to think about what
would happen when items come and go.
Alternatively, If the repository versions indexes, maybe we could use a
previous version of the index instead of the current one.
John
On Nov 8, 2007, at 9:31 AM, Bryan Stearns wrote:
In a discussion on the design list*, Mimi asked for implementation
perspective for a change to cause all the columns to not reorder
immediately when the user changes an item attribute that affects the
current sort.
The triage column currently does this, by keeping two sets of triage
attributes: one set is always present, and controls the color of the
triage button in the detail view and dashboard, and changes
immediately when the user clicks on a button; the other set is only
present when an unpurged triage status change exists on the item (eg,
the user clicked on a button but hasn't clicked the Triage toolbar
button yet) -- the index mechanism uses it in preference to the first
set if it exists.
One way to accomplish this change would be to double all the
attributes this way - this probably wouldn't affect indexing
performance too badly (though the index comparison functions would
look pretty ghastly). However, I don't think this approach would scale
well (and our items are already pretty heavy with attributes) --
however, I haven't thought of another approach yet. I'm also concerned
with how new items (say, received by sharing) would get ordered in an
unpurged collection.
Anyone have any ideas?
...Bryan
*
http://lists.osafoundation.org/pipermail/design/2007-November/thread.html#7789
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
