Chris Withers wrote:
Hi Jim,
Jim Fulton wrote:
BTW, I strongly discourage use of Undo except in emergencies.
Sadly, except when undoing the last (non-undo) transactions in
a database can lead to inconsistency.
What sort of inconsistencies are you referring to?
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.
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.
Russ Ferriday wrote:
> And undo is prominently exposed in Plone, and its use is not discouraged.
> Do you think, Jim, that we should reconsider that?
It was claimed earlier in this thread, that plone only lets you undo the
most recent transactions. If this is true, then that should not be
a problem. A facility that let you only undo "last" transactions
would be safe. It would also be useful, at least for single-user
systems. (Note that definition of "last" gets a little tricky in the
presense of transactional undo.)
I would hazard to guess that most transactions don't have the sort of
problems mentioned above. The problem is that there isn't currently a
good way to separate the problem transaction from the non-problem
ones.
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.
It's possible that, in the future, we will provide an option of recording
both data read and data written in a transaction. Then we could make
undo safe.
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.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
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
