[ZODB-Dev] Re: Savepoints are invalidated once they are used

[Tim Peters]

[Tim Peters]
...
>> I'm not sure I follow this:  old code could not be using savepoints
>> directly, so what would break in code that stuck solely to subtxn
>> commits?
> ...
>> So I don't see how backward compatibility would be injured.  BTW, I
>> tried it, and all the ZODB tests pass with this change.

[Jim Fulton]
> When you so commit(1), the promise is that, if the top-level transaction
> commits, then any work done up to the commit(1) is committed.  Consider
> this scenario:
>
> - new code: s = transaction.savepoint()
> - old code: foo.x = 42
> - old code: transaction.commit(1)
> - new code: s.rollback()
> - old code: transaction.commit()
>
> Now, the old code expected that foo.x was 42.  It did a commit(1). But,
> in fact, if we can roll back s, then in fact, the old code can't count on
> the semantics of the commit(1).  This would be a change in behavior for
> subtransactions.

Right, _mixing_ the two can create surprises, and on both sides (for the new
code too:  since savepoints _do_ nest, I think it's at least as surprising
for the author of the new code that calling old savepoint-free code could
invalidate their savepoint).

> Subtransactions only provide one level of nesting.  They are not the same
> as savepoints.

More, savepoints are better (IMO).

> Now, I don't know for sure that anyone depends on the non-nestedness of
> subtransactions.  Mostly, subtransactions are used to checkpoint
> incomplete changes to disk. So perhaps the backward compatibility risk is
> small.

It would surely be a much happier outcome all around if ZODB users "simply"
stopped using subtxns now.  To set a good example, I think I'll take a bit
of time today to rewrite the parts of ZODB that still use them (there is a
little!  at least one tool script and ExportImport.py).