On Mon, Feb 6, 2012 at 3:10 PM, Julian Reschke <julian.resc...@gmx.de> wrote: > On 2012-02-06 15:02, Stefan Guggisberg wrote: >> >> On Mon, Feb 6, 2012 at 2:39 PM, Thomas Mueller<muel...@adobe.com> wrote: >>> >>> Hi, >>> >>>> Instead of separate Added/Existing/Moved/Removed instances in the >>>> ChangeTree, did you consider keeping the modified content just as >>>> (say) TransientNode instances, without trying to keep track of how >>>> they came to exist? >>>> Then, when you actually need the change log, you >>>> should still be able to construct it by diffing the transient tree >>>> against the persistent base state of the content tree. The only caveat >>>> I know of is that moves can only be reliably detected for >>>> referenceable nodes or ones with an equivalent internal unique ID >>>> (which we shouldn't have trouble doing if needed). >>> >>> >>> So far we don't have any internal unique ID, and I would rather not add >>> one. I think reconstructing the changes by comparing the data is >>> >>> (a) unnecessarily complicated >> >> >> i don't agree, why would that be complicated? >> when using a content-addressable model diff'ing get's even >> extremely efficient. >> >>> (b) wouldn't work for some cases and therefore break observation >> >> >> i partially agree. however, the current jackrabbit implementation >> creates events based on diff'ing states and IMO it works pretty >> well in practice. i am not aware of real world uses cases affected. > > > <https://issues.apache.org/jira/browse/JCR-3207>
agreed, but personally i don't consider this a real world use case. cheers stefan > >> ... > > > Best regards, Julian
