[ZODB-Dev] Ordering before commit hooks

[Dieter Maurer]

Jim Fulton wrote at 2005-8-31 18:02 -0400:
> ...
>> The "order gimmick", while not universal, provides an easy
>> and understandable facility to handle a large group of such
>> use cases.
>
>Huh? It doesn't help these use cases at all.

Of course, it does: together with values assigned by the integrator...

> ...
>> 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).
>
>You might be right, but the only credible use case I've seen
>is to go last.

No "social" hook may require to come last (or first).

We want to enter an open world where independently developed
components can be easily integrated -- ideally by configuration only.
No such component may pose an exclusive claim such as "my callback
must be called the very first" or "the very last".
Instead, they must describe what operations
should be completed before they run -- and leave it to the
integrator to coordinate the various uses of the resource
(in our case the callback).
The framework should provide easy and understandable means for
this coordination work by the integrator.

>The example Julien has something going first
>and something going last.

I am sure Julien did not claim that his callbacks must
be called the first or the last.
Instead, he provided a partial order for his callbacks -- without
restricting third party callbacks.

Depending on what the callbacks do, they may need to go before,
after or between the CPS callbacks.

For example: if the "IndexationManager" would change attributes
(such a e.g. a state "indexed"), then my SQL-store callback
should go after the "IndexationManager"; otherwise it would
not matter (in fact, I do not expect the IndexationManager to change
attributes).

> ...
>The example you gave above had subscribers that wanted to go last.

No, I would not even conceive such components -- because
I want them "social"...

They do *NOT* want to go last. They want to go sufficiently
late such that after they executed, the state they manage
should not change again. This is much weaker than
the requirement to go last: only a single callback can go last,
but a whole family of them (hopefully all required in a given
system) can go sufficiently late.

>What evidence to I have of other orderings?  Julien did give
>a "future need" to order two specific systems.  IMO, having
>one system implement that requirement explicitly by invoking
>the other would be much clearer than having the
>requirement implemented implicitly through integers orders.

You are having a completely different perspective.

Ours is as follows:

  There is a wealth of Zope related "tool boxes": ZODB, Zope, CMF, Archetypes,
  Collectives, CPS, Silva, Plone, a large set of third party products,
  our own toolbox.

  We compose applications from tools of those boxes.
  If necessary, we fix/extend/adapt foreign tools and enhance
  our toolbox. If possible, we want to touch foreign tools only superficially,
  ideally through configuration only.

  If such tools start to use the callback mechanism (I am sure, some
  of them will), this use is likely to be deeply hidden.
  I do not expect that it will be easy (in the sense of touch
  superficially only) to virtualize access by indirecting
  through a coordination component of our own.
  One the other hand, adjusting some "order" parameters only
  seems much easier.

Thus, while you see the situation that one "system" knows
another well and uses its services, I see the situation
of several individually and independently developped "components" 
that I need to integrate -- and I am happy when the basic
coordination means are provided by components below all of them:
Zope, ZODB, CMF.

> ...
>Then propose a common framework.  I have no problem with a common
>framework. Put it in Zope if you want. It doesn't belong
>in ZODB.

Fine.

-- 
Dieter