[ZODB-Dev] Ordering before commit hooks

[Tim Peters]

[Jim Fulton, on Julien's addBeforeCommitHook() change]
> What is the motivation for this?  Can you give any use cases?
>
> I'm -1 on this because it adds complexity to something that I think
> should be simple.  It feels like something that is likely to be missused.
> I do have an open mind though.
>
> Unfortunately, I won't see your reply for over a week.  I'd prefer not to
> see this added to the trunk until we've had a chance to discuss it a bit
> more.

Your message was sent a couple days after the merge to the trunk occurred,
but the merge could be reverted.  I'm happy with it as-is.

The old beforeCommitHook() (which is now deprecated on the trunk) guaranteed
to execute hooks in the order they were registered, so presumably ordering
guarantees were always thought important here.  Allowing to specify an
optional `order` argument in the new addBeforeCommitHook() method gives a
way to influence ordering easier than contorting application code to
register hooks in a specific order.  Dieter gave it a +1, although he didn't
explain why.  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.

The increase in implementation complexity was minimal; in effect, a list
.append() call got changed to a bisect.insort() call; the implementation
code is tiny and easy to understand either way.  The new method replaces the
older method, so the interface didn't grow.  The new method has a better
name and a more robust signature, although those two could be gotten without
adding the optional `order` argument.