[ZODB-Dev] Undo differences between Z2 and Z3

[Chris Withers]

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