jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger" <marcel.reuteg...@day.com>
Subject Re: observing event ordering
Date Tue, 27 Jun 2006 07:44:00 GMT
Hi Florent,

On 6/26/06, Florent Guillaume <fg@nuxeo.com> wrote:
> It seems that JSR-170 doesn't specify any ordering of the events
> returned by the EventIterator.
> Can I assume more ordering from the Jackrabbit implementation?

well, you can but there is no guarantee that it will stay that way.
The current ordering of events is the following:
- item modified events
- item removed events
- item added events

each of the event sets (modified, removed, added) is unordered.

> For instance, if there's addChild() of /foo then a remove() of it,
> can I be sure I'll see NODE_REMOVED before NODE_ADDED?

in jackrabbit this is right now the case. but you should rather
implement a listener that does not rely on ordered events, otherwise
your application is not portable.

> If there's addChild(), remove(), addChild(), remove() of the same
> path, will I see two removes and two adds (it doesn't seem so)?

no, in that case there will be no removes nor adds. but I think there
will be a modified event for the node where you added and then again
removed the child node. afaik jackrabbit does not detect that the
modified parent is in fact again in the same state as before.

> If a node is removed, will I observe a NODE_REMOVED of its children
> before itself?

no, the set of node removed events is unordered.

> You see that for instance I get an ADD of /blob/under before the ADD
> of /blob, and an ADD of /blob/under/jcr:primaryType before /blob/
> under itself, which is counter-intuitive. Should I assume anything?

no, you should not.

> If I'm right nothing is specified

you are right ;)


View raw message