[chandler-users] Annoying modality bug with "Purging..." and
jeffrey at osafoundation.org
Mon Jul 21 17:18:08 PDT 2008
> Umm...that sounds like it is going to make Chandler less usable for
> people with large collections. The purge removed ~5K items from my
> collection. I've not done any timing tests but usually creating entries
> takes longer than purging the dead tuples.
Just to be clear, Mimi's talking about a replace of Purge with
automatically restoring from backup, because purge only gets rid of a
fraction of the redundancy in the repository. So hopefully people with
large repositories will see it as a net gain. But YMMV.
> That said I'm kinda curious, I've not added any entries today, busy
> taking off some ones that have "heft". I've worked on 6-8 of them today
> and just performed a "Compact" and it says it removed 377 objects and 8
> lucene documents. The item to entry ratio seems a bit on the high side.
> I'm also guessing it re-indexes the document which seems a bit like
> unnecessary overhead as I know I didn't change that many of them, mostly
> set the triage status to "done".
The repository stores objects for all UI details. On top of that, it
stores a history of all versions of items. This would be helpful if we
exposed it in the UI for "real" items, but it's not very helpful for UI.
Purge removes (some fraction of) outdated versions of items from the
This architecture came from a time when Chandler was aiming at being
sort of a UI construction kit. That's not really part of the current
vision, so unfortunately putting UI details in the repository is mostly
More information about the chandler-users