>> Would it be sensible for ZODB to do the equivalent of sync() when users
>> call transaction.begin()? That's what I tend to expect it to do
>> anyway--it takes some effort to remember that it doesn't.
> Yes, or commit, or abort. That's what Tim and I were pondering in a part
> of the message you didn't quote. :)
> I imagine that we'll make this so today.
We didn't, but I'm looking at it today's today.
begin() is really a different case than commit()/abort(): the latter two
automagically trigger registered afterCompletion() callbacks, but begin()
does not. Despite the small cognitive dissonance involved, I'm inclined to
make TransactionManager.begin() invoke registered afterCompletion()
callbacks. (Note that Transaction.begin() is deprecated, and I'm not keen
to add new functionality to deprecated stuff.)
AFAICT, it would make more sense to move the logic for invoking callbacks
into TransactionManager. Transaction() currently takes an optional
`sychronizers` argument that it never mutates, for which a
TransactionManager always passes its set of registered synchronizers. Since
ISynchronizer hooks are registered with a transaction manager rather than
with a transaction, it makes more sense to me for the transaction manager to
invoke them (as is, we're duplicating a TM instance var inside every T).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org