On Wednesday 23 December 2009 20:26:13 Jim Fulton wrote:
> Undo is broken in a number of ways. Does anyone care? Does anyone use
First, a disclaimer: what I state below is from Zope 2.8-ish experiences, with
its original ZODB version. I hope my mail is still on topic nevertheless.
In my company, it is gradually becoming a production-server-setup step to
disable (remove via monkey patch) the "undo" tab from Zope's ZMI, because it
happens quite often for someone to click on it on a multi-gigabyte FileStorage
via Zeo, causing the whole cluster to go down until someone restarts Zope &
Zeo or a few hours pass.
This is due to the backward seeking done when listing transactions to undo
(disk throughput goes down to a crawl) filtered by context path (depending on
the path, the given limit of transactions to display will never be reached)
and with storage lock taken, effectively bringing the cluster down.
So I believe that this performance issue, although being less serious than
what you present as technical breakage, is a showstopper by itself in practise
(unless it becomes impossible to filter transactions to undo, making the
action end in a roughly constant time for a given transaction number). Maybe
this would be an argument toward offline-only undo support.
Finally, I believe that undo feature is miss-represented in Zope (keep above
disclaimer in mind: I don't know about most recent Zopes), because most people
I know who used that "undo" tab are actually interested in undoing
transactions modifying context, not transaction done on context (so they
actually want to use the efficient "history" tab, the one using FileStorage
object version back-pointers).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org