[ZODB-Dev] Ordering before commit hooks

[Jim Fulton]

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

Minor note, AFAICT, Julien really only needed to assure that his event hook
ran last.  He could have done this easily without the order feature by registering
an intermediate hook that registered the event hook when it was called.

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

Another way to say this is that it pushes application policy into ZODB.
Different applications will likely need other policies.

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

-1 on order.  Your note strengthened my opposition.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org