[ZODB-Dev] Ordering before commit hooks

[Tim Peters]

[Julien Anguenot]
> ...
> To make it clear the idea is if you got this and if we call it "order".
>
> Callback Ca order 0
> Callback Cb order 999999
> Callback Cc order -999999
>
> The order of execution will be Cc Ca and then Cb.
>
> Note the ones with a default order (e.g : 0) will be executed in the
> order of the regitration as it is currently.

Isn't it also true that if, e.g., Cd were added last with `order` 999999,
then it's guaranteed that Cb is invoked before Cd?  That is, is there
something unique about 0 wrt "equal orders fire in registration order"?  I
hope not.

> You ok with this ?

Yup.  Does it end here?  Or is this an ever-growing subsystem, also
"needing" ways to query the `order` value associated with callbacks already
registered, ways to change their associated `order` values, ...?  Note that
it would be incompatible if getBeforeCommitHooks() changed to return the
`order` values too.

> Note, the wording 'order' comes from Jim's implementation within Zope3
> that I wanted to follow for consistency.
>
>
http://svn.zope.org/Zope3/trunk/src/zope/configuration/interfaces.py?rev=375
52&view=auto
>
> IConfigurationContext.action() for instance. an action with order 9999999
> will be invoked after the other ones.

That may be the case, but the interface docstring there doesn't explain
anything about the effect of action's `order` argument.  I would, of course,
like an accurate docstring in ZODB.

> And, of course, if it's called a priority then the execution will be be
> the opposite : Cb, Ca, Cc
>
> Now, it's probably better to use "order" to keep consistency with Zope3.

Well, Gary thought "priority" would give the same ordering as "order", so
"priority" instead sure isn't winning on universal obviousness <wink>.
"order" is fine with me, and everyone so far guessed its intended meaning.

>> It's certainly easy to implement.  The Collector will remain open all
>> weekend for patches <wink>.

> Well, I'd rather do a branch including the modifications and the tests
> that we could merge after. For you and for me it will be easier. Except
> if the ZODB sub-area of the Zope.org repository is a resticted one ?

Fine idea!  Since it's a new feature, it would need to be done on a branch
off of ZODB/trunk (current 3.5 development).  ZODB is not restricted (well,
no more than Zope or Zope3 are restricted -- you need zope.org commit
privileges to fiddle with any of them).

Note that it's specifically allowed to register additional hooks _while_
before-commit hooks are being invoked, so it's likely easiest to maintain
the _before_commit list in sorted order all along (via bisect.insort(), and
including a unique index number in the tuple inserted to resolve `order`
ties in registration order), or to use a BTree-based container instead. 

It's tricky to implement this in a way that scales efficiently to a "large
number" of hooks.  I assume that's not a problem, because the current
implementation doesn't scale efficiently either (it's quadratic-time in the
number of hooks), and nobody has complained about that.