Tim Peters wrote:
[Christian Heimes, suggests changing Transaction.commit() to start with
if subtransaction:
# TODO deprecate subtransactions
self._subtransaction_savepoint = self.savepoint(1)
return
if self._savepoint2index:
self._invalidate_all_savepoints()
i.e. swapping the first two blocks]
[Jim Fulton]
subtransactions != savepoints
There is *no* promise of nestability with subtransactions. Committing a
subtransaction invalidates prior savepoints by design. This is necessary
to maintain backward compatibility.
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.
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.
Subtransactions only provide one level of nesting. They are
not the same as savepoints.
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.
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
