jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3 microkernel] Change log consolidation
Date Mon, 06 Feb 2012 14:02:17 GMT
On Mon, Feb 6, 2012 at 2:39 PM, Thomas Mueller <mueller@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.


> Regards,
> Thomas

View raw message