>> 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
>> So I don't see how backward compatibility would be injured. BTW, I
>> tried it, and all the ZODB tests pass with this change.
> 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
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
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).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org