jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: EventIterator order of events
Date Wed, 15 Aug 2007 13:28:59 GMT
On 8/14/07, Marcel Reutegger <marcel.reutegger@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
>

Mime
View raw message