[ZODB-Dev] Ordering before commit hooks

[Dieter Maurer]

Jim Fulton wrote at 2005-8-31 10:20 -0400:
> ...
>> 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)
>
>Except that, as Tim and I have pointed out, the order gimmic didn't
>deal at all well with the use case of making something go last.

Did you read my message?

  The "order gimmic" provides a global scale along which
  an *integrator* can align hooks according to their
  relative needs (if they do not conflict altogether).

  He (the integrator!) assigns orders to all hooks and can
  let individual hooks go at the start, the end, in the middle
  whereever it is necessary -- in a an (quite) easy and
  understandable way (the "import order" of packages might
  be an approximation -- but far less understandable and flexible
  and more error prone).


I am starting to get a bit tired with this discussion.

  I live since a long time with enhanced versions of Zope/ZODB.
  This can stay so, if improvements take too much effort
  to get them into the core.

  Another alternative would be to publish a standard extension package, that
  provides the (trivial) ordering.
  The only difficulty with this: It provides a *global*
  coordination facility; it would need to be available
  in all systems that anticipate a hook coordination need.
  The only advantage the ZODB has wrt. this solution:
  It is available everywhere.

> ...
>> 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 ?
>
>What if you want one callback to go immediately after another?  What
>if you want a callback to be called only if another wasn't called (or
>was called). These are also legitimate policies that the order gimmick
>doesn't address.  They are policies that can be handled by a higher-level
>plug-in.

That's true -- apart from the fact that you have not yet shown
the real life use cases for these hypothetical policies.

It appears to me that these policies entail significant knowledge
among the various hooks about themselves. Such cases may
need specific solutions.


Our use cases (at least mine) for the "order gimmick" come from a common 
root: the wish to perform a summary operation once before
the commit rather then partial operations over and over again
during the transactions: e.g.:

  *  one summary SQL UPDATE for the complete modified record
     rather than an SQL UPDATE for each attribute modification

  *  one summary "index_object" rather than lots
     of "index_object" calls for each individual modification.

The have order requirements (they should come after all possible
modifications that should go into the summary operation) but
they are not too strong.

The "order gimmick", while not universal, provides an easy
and understandable facility to handle a large group of such
use cases.

> ...
>> Jim, honestly where is the complication ?
>
>The API gets an extra argument who's use is far from clear.  People
>reading the API would rightly wonder why they would use it.

Ordering the execution of hooks is not that unfamiliar.
Doing it by means of numbers, neither...

> What
>does it gain them?

There are few developpers who will use the hook, many hooks
will not need an explicit ordering. A developper who has
specific needs with guess what "order" is for ;-)

> If they wanted something to go last (or first),
>what argument should they provide?

Contrary to your opinion, hooks will probably rarely have the
need to be called as the very first or the very last one.
Usually, the requirements will be: after I was executed
some (hook) specific things should not happen anymore (because,
otherwise, I would need to run again).

> ...
>Right. You need to use a common API. So define one and get people to use
>it. You *want* the common API to be defined by ZODB.

Indeed, because then (almost) all ZODB users with hook synchronization
needs can use it.

> That's too low level.

The amount of "common components" available for the resource *coordination*
of independently developed packages is not so large.


If it does not go into the ZODB, then almost surely, competing
solutions will spring up that locally (e.g. for CPS, Plone, MySelf, Archetypes,
...) will do the job, causing pain when packages from these different worlds
are integrated.


It would be nice, if a common solution could be established
at or below CMF (as most of the worlds above are above it) -- but
after this discussion, I fear, it will not happen...


-- 
Dieter