-----BEGIN PGP SIGNED MESSAGE-----
Tim Peters wrote:
> [Victor Safronovich]
>>it should be better to add addAfterCommitHook to transaction
>>as in addBeforeCommitHook.
yup it could be really useful to trigger non transactionnal code from
there. We might use this in here with our CPSRelation product and the
rdf db we are using. I could find a project to test this in real life :)
> Sounds like a reasonable idea to me. Who wants to implement it? (It should
> be done on a branch off of current ZODB trunk, which is current ZODB 3.6
I can take care of this if nobody else is interested to do it. I can
surely do this by the end of the week.
> The first thing to do is to define the interface. Here's one possibility,
> modeled after addBeforeCommitHook(). The major difference is that a
> true/false value is passed to the hook unconditionally, to tell the hook
> whether the commit attempt succeeded (true) or aborted (false):
> def addAfterCommitHook(hook, args=(), kws=None):
> """Register a hook to call after a transaction commit attempt.
> The specified hook function will be called after the transaction
> commit succeeds or aborts. The first argument passed to the hook
> is a Boolean value, true if the commit succeeded, or false if the
> commit aborted. `args` specifies additional positional, and `kws`
> keyword, arguments to pass to the hook. `args` is a sequence of
> positional arguments to be passed, defaulting to an empty tuple
> (only the true/false success argument is passed). `kws` is a
> dictionary of keyword argument names and values to be passed, or
> the default None (no keyword arguments are passed).
> Multiple hooks can be registered and will be called in the order they
> were registered (first registered, first called). This method can
> also be called from a hook: an executing hook can register more
> hooks. Applications should take care to avoid creating infinite loops
> by recursively registering hooks.
> Hooks are called only for a top-level commit. A subtransaction
> commit or savepoint creation does not call any hooks. Calling a
> hook "consumes" its registration: hook registrations do not
> persist across transactions. If it's desired to call the same
> hook on every transaction commit, then addAfterCommitHook() must be
> called with that hook during every transaction; in such a case
> consider registering a synchronizer object via a TransactionManager's
> registerSynch() method instead.
> Fuzzy: what happens if an after-commit hook invokes addBeforeCommitHook()?
> I think it should be a (detected) error. (The current transaction is
> winding down, and it's "too early" to try adding hooks to the next
> transaction -- it doesn't exist yet.)
When you mean "detected error" you mean an exception is raised or just
the error is caught and ignored within the internals ?
> Fuzzy: should after-commit hooks be called before or after the
> afterCompletion() methods of registered synchronizers? The analogous
> question wrt before-commit hooks and beforeCompletion() methods was left
> unanswered, and I'm happy enough leaving it undefined here too.
Let's discuss and fix this in a second step for both before and after
commit hook system ?
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org