Jim Fulton wrote:
Logical inconsistencies. Consider two transactions, T1
and T2 that run the same code:
def f():
if 'x' not in somefolder:
somefolder['x'] = 42
The postcondition of the transaction is that somefolder
has an item named 'x' with the value 42.
Now, when T2 runs, it doesn't add the item to the folder,
because T1 added it. We can undo T2 without problem.
Ah, okay.
If we undo T1 without undoing T2, we do have a problem.
Our current system doesn't detect the coflict between T2 and T1
because T2 read the folder but didn't write it. We don't track
reads, so we don't recognize the conflict.
Even if you did track reads, how would you distinguish an "unsafe" read
as above from a "normal" read that shouldn't cause a conflict?
Ther are many situations where the benefits of undo outweight the risks,
which is why I still favor making it available as an adminstrative feature.
Indeed, and provided the transactions created by the application are
careful to avoid problems of the above type, I think it's safe to
provide "full" undo support, but the burden _is_ then on the app
developer to make sure they do nothing unsafe when it matters.
For now, the issue is mostly moot, since in most applications,
transactions you want to undo tend to conflict with later ones, even
with the limited conflict detection we use now.
Hmmm, I guess a "copy to present" system, as provided in History.py,
might well do better for "application level" undo...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
