[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?
The internal savepoint used to implement commit(1) now isn't exposed to
users, so they couldn't roll back directly to older subtxn commits, and the
transaction internals only remember the (internal) savepoint for the most
recent commit(1) done.
So I don't see how backward compatibility would be injured. BTW, I tried
it, and all the ZODB tests pass with this change.
> If you don't like this behavior, don't use subtransactions. A good
> community project would be to convert all of the subtransaction calls in
> Zope to savepoint calls.
Yup. Speaking of which, some of the comments say subtxns are deprecated,
but they're not really. It's too late to deprecate them in 3.4 (for 3.6).
Is it OK to deprecate them now in 3.5 (for 3.7)? I would like to, and
deprecation nags are good motivators. If not 3.5, in 3.6 (for 3.8)?
_______________________________________________
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
