[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. _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
