On 8/14/07, Marcel Reutegger <[EMAIL PROTECTED]> 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 >
