jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3 microkernel] Change log consolidation
Date Mon, 06 Feb 2012 13:39:22 GMT

>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
(b) wouldn't work for some cases and therefore break observation

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.


View raw message