Re: [ZODB-Dev] Ordering before commit hooks

[Dieter Maurer]

Jim Fulton wrote at 2005-8-23 14:22 -0400:
 ...
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.
 
 
 Now plug and play comes into play:
 
   Assume two packages developped by independent people
   which all want to control the order of hook execution.

Do we have evidence that such applications exist? So far, the
only example I've seen is one where an application wanted a handler
to go last. As I've pointed out in a separate note, this is achievable
without the change.

I have a *package* (similar to Archetypes SQLStorage) that
wants to go after everything that might possibly change attributes
whether those changes are done by another component from me
or any package developped by someone else.

-- 
Dieter
___
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

Re: [ZODB-Dev] Ordering before commit hooks

[Jeremy Hylton]

On 8/22/05, Tim Peters [EMAIL PROTECTED] wrote:
 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.

I think that's the right reasoning.  I agree with Jim.

The transaction manager coordinates the actions of unconnected
resource managers.  If there are several transaction participants that
are all part of the same software package, they can provide their own
internal ordering as you suggest.  If they are not related, then
there's no reason to think they care about their order relative to
other participants they know nothing about.  To the extent that
software cares about order, there is likely a simple partial order
(run before X) rather than the total order that order= suggests to me.

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

Keep it out.

Jeremy
___
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