-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremy Hylton wrote:
> 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 understand this argument Jeremy. But check Dieter argument about the
ability of registering hooks with zcml directive for instance.
The good think by keeping the order parameter is that you can use *both*.
The 'order' parameter provided by the transaction *and* the ability of
coding your own object managing this if your system has a complex use of
the before commit hooks. (at least more complex than *just* the order of
the hooks) You may think about execution dependencies for instance.
Then it would the responsability of the framework (on top of ZODB) to
manage its complex logic. This use case will be rare and really complex
framework will deal with that in their internals. Here, I agree with you.
But when an integrator (or devel) will have to register a commit hook he
will be happy to be able to control easily the order of its hooks
without having to think about coding it's object managing this. Again,
it's overkill in simple situations.
You're not convincing me for simple situations
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
iD8DBQFDEwSYGhoG8MxZ/pIRAlVgAJ9TwP3Q7h9b7OGCLwIWCLI6RCnT5gCeJNlr
MmeuazztsvEW4f0FH5/aYeY=
=/Lye
-----END PGP SIGNATURE-----
_______________________________________________
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
