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. > > The JCR API does define operations (move, add, remove, reorder...), and > for observation we need them. The most simple solution is to keep the > events. Why throw the events away if you need them later. > > An example for (b) is multiple reorder operations within the same node. personally i don't see the practical value in representing multiple reorder operations within a single save rather than consolidating them. cheers stefan > > Regards, > Thomas >
