[ZODB-Dev] undo (and storage interface) brokenness

[Vincent Pelletier]

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
>  undo?

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).

-- 
Vincent Pelletier