Re: [ZODB-Dev] Ordering before commit hooks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Julien Anguenot wrote: I'm gonna respond to a number of emails at once. :) Tim Peters wrote: [Tim] ... Julien provided links to code that already uses the new feature: As an Indexation Manager : http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/IndexationManager.py As an Event Manager : http://svn.nuxeo.org/trac/pub/file/CPSSubscriptions/trunk/EventManager.py He appears to use (just) two distinct `order` levels there, and seems just to want to make sure one class of hook gets run before the other class of hook. The new scheme does give an easy way to do that. OTOH, while picking levels of -100 and 100 works for that specific use case, looks like it threatens to become a mess if multiple subsystems try to use this scheme simultaneously. We discussed quickly about this with Florent. This can be expressed by having a coding guide for the given framework (for instance CPS). We will provide ranges in which hooks are executed. Then if someone wants to register another one he can check the existing ones and the ranges they are using and what they are doing. Just a matter of documentation. Of course, this doesn't work across projects. ok here we agree :) For example, someone who wants to be the last kind of hook invoked has no way to force that, at least not short of passing sys.maxint as the `order`. But if that's what's needed, `sys.maxint` is a strange way to spell it. I understand it but this is something that could be done by extending the transaction hooks sub-system. But again we don't have YAGNI yet for a bigger sub-system that could include this. The very fact that to really do what you need to do today would require an extension indicates that the current API isn't what we should be doing. We'll never have what every application needs anyway, which is why this ordering logic should be at the application level where it's easy to control. I don't understand why keeping the order paremeter is such a big deal ? Because it clutters the ZODB API with something that is, fundamentally application policy. Here we disagree. I could agree if only one hook could be registred instead of a severals (within a tiny little tuple :) ). Then you could say : It's application logic just register your object as *the* hook that will deal with the order of execution of other sub-hooks your system defines Here, it's not the case because you can register several within a transaction and actually the ZODB has already a policy regarding this which is executing it in the order they've been registred. Thus my proposal could be seen as well as a request to change (or to make more flexible) the policy already in place. (Which was my use case) It prevents me having to code my own specific object dealing with this Dealing with what? Dealing with the order of execution. Your original need was to make something go last. Well yes and no. What if I want to go first instead ? Or in the middle of 2 independently (external to my system) defined hooks ? As Tim pointed out, the order api doesn't do that and, as I've pointed out, the existing API does deal with that. no. not enough flexibility. and I'm sure other people will benefit from this later on when they will have to use this transaction feature. That's hypothetical. In any case, if you are so sure, provide a system that does this and let people use it. You don't need to make ZODB more complicated to address this use case. Jim, honestly where is the complication ? Dieter Maurer wrote: Tim Peters wrote at 2005-8-22 16:48 -0400: ... Jim still wonders, and he got me wondering too, whether the `order=` gimmick is really needed. But, it is a very easy concept -- both easy to grasp as well as easy to implement. Just because it's an easy concept, doesn't mean it belongs in in the transaction layer. It would be just as easy a concept as a ZODB add-on. I wouldn't object to such a thing in Zope, for example. Then don't allow the registration of several hooks. Just provide one slot to register only one. Then I could be fine with this. Let's imagine : I got the following hypotetical architecture : Let's say I follow what you're saying. - -- ZODB Zope3 - defines hook A (managing perhaps other hooks and manage the order of execution of its sub-hooks) z3ecm - define hook B (idem A) CPS4 - define hook C (idem A) - --- Imagine within the top layer (CPS4) I want to execute one of my hook in between two of the Zope3 and z3ecm hooks ? I definitely Can't... Julien Anguenot wrote: Jim Fulton wrote: ... 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. We have. We are thinking of adding another hook within CPS to
Re: [ZODB-Dev] Ordering before commit hooks
Jim Fulton wrote at 2005-8-24 16:08 -0400: ... 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. So again, you don't need ordeing, you just want to go last. Just register an intermediate hook that registers the real hook when it is called. I do not understand this argument: Now you already know two components from which you think they would want to come last (mine and that of Nuxedo). But only one can win. Fortunately, neither of these components really requires to come last. Instead, they require to come after some other hooks with some behaviour (mine wants to come after any hook that may still modify any attributes). These requirements are difficult to formalise. However, having a global scale (such as the order argument), *configuration* (by an intelligent person) can assign order values to the various components such that there requirements are met. -- 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
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
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
RE: [ZODB-Dev] Ordering before commit hooks
[Tim] ... Julien provided links to code that already uses the new feature: As an Indexation Manager : http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/IndexationManager.py As an Event Manager : http://svn.nuxeo.org/trac/pub/file/CPSSubscriptions/trunk/EventManager.py He appears to use (just) two distinct `order` levels there, and seems just to want to make sure one class of hook gets run before the other class of hook. The new scheme does give an easy way to do that. OTOH, while picking levels of -100 and 100 works for that specific use case, looks like it threatens to become a mess if multiple subsystems try to use this scheme simultaneously. For example, someone who wants to be the last kind of hook invoked has no way to force that, at least not short of passing sys.maxint as the `order`. But if that's what's needed, `sys.maxint` is a strange way to spell it. 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'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? ___ 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
Tim Peters wrote: [Tim] ... Julien provided links to code that already uses the new feature: As an Indexation Manager : http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/IndexationManager.py As an Event Manager : http://svn.nuxeo.org/trac/pub/file/CPSSubscriptions/trunk/EventManager.py He appears to use (just) two distinct `order` levels there, and seems just to want to make sure one class of hook gets run before the other class of hook. The new scheme does give an easy way to do that. OTOH, while picking levels of -100 and 100 works for that specific use case, looks like it threatens to become a mess if multiple subsystems try to use this scheme simultaneously. For example, someone who wants to be the last kind of hook invoked has no way to force that, at least not short of passing sys.maxint as the `order`. But if that's what's needed, `sys.maxint` is a strange way to spell it. 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. Minor note, AFAICT, Julien really only needed to assure that his event hook ran last. He could have done this easily without the order feature by registering an intermediate hook that registered the event hook when it was called. 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. Another way to say this is that it pushes application policy into ZODB. Different applications will likely need other policies. 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? -1 on order. Your note strengthened my opposition. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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
[Jim Fulton, on Julien's addBeforeCommitHook() change] What is the motivation for this? Can you give any use cases? I'm -1 on this because it adds complexity to something that I think should be simple. It feels like something that is likely to be missused. I do have an open mind though. Unfortunately, I won't see your reply for over a week. I'd prefer not to see this added to the trunk until we've had a chance to discuss it a bit more. Your message was sent a couple days after the merge to the trunk occurred, but the merge could be reverted. I'm happy with it as-is. The old beforeCommitHook() (which is now deprecated on the trunk) guaranteed to execute hooks in the order they were registered, so presumably ordering guarantees were always thought important here. Allowing to specify an optional `order` argument in the new addBeforeCommitHook() method gives a way to influence ordering easier than contorting application code to register hooks in a specific order. Dieter gave it a +1, although he didn't explain why. Julien provided links to code that already uses the new feature: As an Indexation Manager : http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/IndexationManager.py As an Event Manager : http://svn.nuxeo.org/trac/pub/file/CPSSubscriptions/trunk/EventManager.py He appears to use (just) two distinct `order` levels there, and seems just to want to make sure one class of hook gets run before the other class of hook. The new scheme does give an easy way to do that. The increase in implementation complexity was minimal; in effect, a list .append() call got changed to a bisect.insort() call; the implementation code is tiny and easy to understand either way. The new method replaces the older method, so the interface didn't grow. The new method has a better name and a more robust signature, although those two could be gotten without adding the optional `order` argument. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Julien Anguenot wrote: [...] I would like to order the before commit hooks on a transaction by being able to specify an order for a subscriber at registration time. For the moment, they are called in the order they've been registred. [...] What do you think ? What is the motivation for this? Can you give any use cases? sure. It was a YAGNI driven proposal. We used the beforeCommitHook support since the beginning on CPS for content indexation optimizations. For this, we defined an indexation manager registred as a before commit hook assuring us that, for a given content, it would be indexed only *once* per transaction (including security indexation). FYI, it's not the current behavior at all on a stock CMF. (You can get until 5 times reindexation for the same object and this is really a pb when you get a *really huge* catalog, SQL or not) Then, recently I wanted to use the same pattern for the events received by the system that we were using for user notifications. So same idea, an event manager hook registred as before commit hook. Problem : no way of being sure that the event manager would be called *after* the indexation manager because I wanted to be sure to get the potential events the indexation manager could raise. The idea is pretty clear, isn't it ? Feel free to ask for CPS code pointers on this. I'm -1 on this because it adds complexity to something that I think should be simple. I disagree, it doesn't add that much complexity. Basically, one more 'order' argument and adding the hook in a sorted tuple. It feels like something that is likely to be missused. Not sure I get this. I do have an open mind though. great. Unfortunately, I won't see your reply for over a week. I'd prefer not to see this added to the trunk until we've had a chance to discuss it a bit more. I did the job in a branch following Tim's advices for the implementation last week and he actually merged the devel branch yesterday. J. - -- Julien Anguenot | Nuxeo RD (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 iD8DBQFC/3JHGhoG8MxZ/pIRAnpoAJ9os0UJkELYh/7k/zgpHtw9+j4wnACePdvm FUMapVGbHA/ZIMwD0CLqeD8= =2TL1 -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
Re: [ZODB-Dev] Ordering before commit hooks
-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 99 Callback Cc order -99 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` 99, 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 52view=auto IConfigurationContext.action() for instance. an action with order 999 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 RD (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- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I created a branch there : http://svn.zope.org/ZODB/branches/anguenot-ordering-beforecommitsubscribers/ See changeset 37789 Check the changeset log for more information about the implementation. J. Julien Anguenot wrote: Hi, I would like to order the before commit hooks on a transaction by being able to specify an order for a subscriber at registration time. For the moment, they are called in the order they've been registred. The order argument could be an integer with a default value to 0 added to the registration method. We could just insert the subscriber wihin the queue according to this order parameter if found *or* sorting the queue according to this parameter before flushing the queue and calling the hooks. What do you think ? J. ___ 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 - -- Julien Anguenot | Nuxeo RD (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 iD8DBQFC94hMGhoG8MxZ/pIRAiUBAJ4pSURhy/eJVTADup9n4ZCsMsYc6ACfU+Wp 8U5RRBJmIJwgXKS4rtyz9OE= =+UCj -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
[ZODB-Dev] Ordering before commit hooks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to order the before commit hooks on a transaction by being able to specify an order for a subscriber at registration time. For the moment, they are called in the order they've been registred. The order argument could be an integer with a default value to 0 added to the registration method. We could just insert the subscriber wihin the queue according to this order parameter if found *or* sorting the queue according to this parameter before flushing the queue and calling the hooks. What do you think ? J. - -- Julien Anguenot | Nuxeo RD (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 iD8DBQFC8z2CGhoG8MxZ/pIRAu8sAJ4vHRVCMcNNQoRUVZaxQ6risIdzlgCcDhAl EVYn/Ew0jXfhUn+d4WMdvhk= =dkcf -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
Re: [ZODB-Dev] Ordering before commit hooks
On Aug 5, 2005, at 6:20 AM, Julien Anguenot wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to order the before commit hooks on a transaction by being able to specify an order for a subscriber at registration time. For the moment, they are called in the order they've been registred. I like this idea, and was just idly wishing for it this morning. The order argument could be an integer with a default value to 0 added to the registration method. I usually like the word 'priority' for this sort of value, rather than 'order'. To me 'order' implies unique value--i.e., with 'order' I am mildly surprised to learn that two entries may have the same order. I am not surprised that two entries may share a priority. If negative values are acceptable then a default value of 0 is OK by me. We could just insert the subscriber wihin the queue according to this order parameter if found *or* sorting the queue according to this parameter before flushing the queue and calling the hooks. I think it would be ideal if before commit hooks with the same priority continue to be in the order in which they were added. There are a number of ways to accomplish this and I expect you can choose a very reasonable one :-) Gary ___ 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
On Aug 5, 2005, at 2:33 PM, Tim Peters wrote: [Julien Anguenot] ... The order argument could be an integer with a default value to 0 added to the registration method. [Gary Poster] I usually like the word 'priority' for this sort of value, rather than 'order'. To me 'order' implies unique value--i.e., with 'order' I am mildly surprised to learn that two entries may have the same order. I am not surprised that two entries may share a priority. It's wholly unclear to me, given a callback with associated value 0 and another with associated value 999, which one is supposed to be invoked first. If the parameter is called priority, then I'd expect 999 to win; if it's called order, then 0. To each his own, I suppose--'first priority' and 'last priority' is my model, in which, at the least, a priority of 1 would be first priority and a priority of 999 is a reasonable last priority (acknowledging a positive infinity as something that would take the honor of being reliably last priority, then). A priority of 0, and a negative priority, start to muddle the model a bit, certainly. But anyway, if you don't see 'priority' in that way, then yes, it is perhaps unclear in a different dimension than 'order' is unclear. :-) Gary ___ 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
