[ZODB-Dev] Ordering before commit hooks

[Julien Anguenot]

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

Tim Peters wrote:
> [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.

It will have the same behavior as 0, of course. I badly took 0 as an
example...

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

It's enough for us right now.

> Note that
> it would be incompatible if getBeforeCommitHooks() changed to return the
> `order` values too.
> 

right.

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

I'll add this to do doctest right now on Zope3.

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

;) Let's go for order then.

> "order" is fine with me, and everyone so far guessed its intended meaning.
> 
> 

cool

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

then it's fine.

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

ok I'll check this.

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

It's not currently a problem for us with CPS.


	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

iD8DBQFC9y26GhoG8MxZ/pIRAv5UAJ42T5CX1cy8FMBewUDKVS6KcldAlwCeLBB5
ISAD/pZKuhHY2YT7CsIzyQY=
=b5tB
-----END PGP SIGNATURE-----