Re: EventIterator order of events

[Marcel Reutegger <ma...@gmx.net>]

Alessandro Bologna wrote:
> I did not see anything in the current specs (and I did not have a chance 
> yet to review JSR-283), but is there a reason for this inversion of order?

the spec doesn't prescribe an order on the events. that is, you shouldn't rely 
on a specific order.

as for jackrabbit, the order is depth-first because of this method:
SessionItemStateManager.getDescendantTransientItemStates(NodeId). However, I 
don't know what the exact reasons are for that. the observation manager then 
simply uses the same sequence of items to create events. It seems 
counter-intuitive and I'm tempted to change the event creation logic to build 
the event list in reverse order. but again, you should not rely on a specific 
order in your application because it is implementation dependent.

regards
  marcel

Re: EventIterator order of events

[Stefan Guggisberg <st...@gmail.com>]

On 8/14/07, Marcel Reutegger <ma...@gmx.net> wrote:
> Alessandro Bologna wrote:
> > I did not see anything in the current specs (and I did not have a chance
> > yet to review JSR-283), but is there a reason for this inversion of order?
>
> the spec doesn't prescribe an order on the events. that is, you shouldn't rely
> on a specific order.
>
> as for jackrabbit, the order is depth-first because of this method:
> SessionItemStateManager.getDescendantTransientItemStates(NodeId). However, I
> don't know what the exact reasons are for that. the observation manager then

this seems to be a leftover from very early implementations. since i
wrote this code about 4-5 years ago i have only a sketchy recollection ;-)

i guess the depth-first order was used to prevent dangling references
(child node entries pointing to non-existent items) in case of a failure during
write operations.

with the current code this shouldn't be a concern anymore, so the order of
items returned by getDescendantTransientItemStates/InAttic()
could probably be changed.

cheers
stefan

> simply uses the same sequence of items to create events. It seems
> counter-intuitive and I'm tempted to change the event creation logic to build
> the event list in reverse order. but again, you should not rely on a specific
> order in your application because it is implementation dependent.
>
> regards
>   marcel
>