Hello, I am currently building a simple replication between two Jackrabbit instances. I've started off using (synchronous) Observers/Events but I am facing some challenges due to the (intresting?) event order. E.g. I add a file (using webdav) I see the following events (in that order): > PROPERTY_ADDED,2@4376: /Somefile.png/jcr:content/jcr:data > PROPERTY_ADDED,1@4377: /Somefile.png/jcr:content/jcr:mimeType > PROPERTY_ADDED,7@4378: /Somefile.png/jcr:content/jcr:primaryType > PROPERTY_ADDED,5@4379: /Somefile.png/jcr:content/jcr:lastModified > PROPERTY_ADDED,5@4380: /Somefile.png/jcr:created > NODE_ADDED@4381: /Somefile.png/jcr:content > PROPERTY_ADDED,1@4382: /Somefile.png/jcr:createdBy > PROPERTY_ADDED,7@4383: /Somefile.png/jcr:primaryType > NODE_ADDED@4384 :/Somefile.png
Of course I can not replay the events in that order as some parent nodes may be missing. I could re-order them but then this would at least require some "unit of work" demarcation as I operate on stream of events (and thus need to cluster/chunk) the events. Is there a reason why the events are emitted in 'reverse' order (I would assume per API the node was created first)? Is there a way to influence this? Afaik PERSIST (event bundling) is work-in-progress in unstable, would that be a candidate as Unit-Of-Work marker? Cheers, Ingomar
