[ZODB-Dev] Ordering before commit hooks

[Julien Anguenot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Peters wrote:
> [Tim]
> 
>>...
>>Julien provided links to code that already uses the new feature:
>>
>>""" As an Indexation Manager :
>>http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/IndexationManager.py
>>
>>As an Event Manager :
>>http://svn.nuxeo.org/trac/pub/file/CPSSubscriptions/trunk/EventManager.py
>>"""
>>
>>He appears to use (just) two distinct `order` levels there, and seems
>>just to want to make sure one class of hook gets run before the other
>>class of hook.  The new scheme does give an easy way to do that.
> 
> 
> OTOH, while picking levels of -100 and 100 works for that specific use case,
> looks like it threatens to become a mess if multiple subsystems try to use
> this scheme simultaneously.  

We discussed quickly about this with Florent. This can be expressed by
having a coding guide for the given framework (for instance CPS). We
will provide ranges in which hooks are executed. Then if someone wants
to register another one he can check the existing ones and the ranges
they are using and what they are doing. Just a matter of documentation.

> For example, someone who wants to be "the last
> kind of hook invoked" has no way to force that, at least not short of
> passing sys.maxint as the `order`.  But if that's what's needed,
> `sys.maxint` is a strange way to spell it.

I understand it but this is something that could be done by extending
the transaction hooks sub-system. But again we don't have YAGNI yet for
a bigger sub-system that could include this.

> 
> Jim still wonders, and he got me wondering too, whether the `order=` gimmick
> is really needed.  For example, you could have gotten to the same end here
> with the old method, by registering your actions with an object of your own
> creation, and registering just one commit hook with the transaction, where
> that one hook looked at the actions you registered with your own object and
> ran them in whatever order _it_ determined was best.  The ordering logic
> would have been out of ZODB then, not limited to what an integer `order` can
> express, and might even benefit from "ah, if I have to run A, then there's
> no need to also run B or C" kinds of optimizations.
> 
> I'm inclined to agree with Jim that `order=` wasn't needed; that it was too
> general for the specific use case we've seen; and that it's not general
> enough for plausible other use cases.
> 
> Should this really go into ZODB 3.5?  The method name change and robustified
> signature were good improvements, and I'd certainly like to keep them.  I
> think the jury is still out on `order`, though.  Anyone else have strong
> feelings for or against it?
> 

I don't understand why keeping the order paremeter is such a big deal ?
It prevents me having to code my own specific object dealing with this
and I'm sure other people will benefit from this later on when they will
have to use this transaction feature.

So yes I'd like to keep this within ZODB 3.5 ;)

Cheers,

	J.


- --
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

iD8DBQFDEv+zGhoG8MxZ/pIRAhduAJ9/SGCtyVZ3TmGF4QNjRsyR/fA87ACdELw9
2L1e1oYpTPu9GM1EYOhNRko=
=K282
-----END PGP SIGNATURE-----