jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: [jr3 microkernel] Change log consolidation
Date Mon, 06 Feb 2012 14:10:19 GMT
On 2012-02-06 15:02, Stefan Guggisberg wrote:
> 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.

<https://issues.apache.org/jira/browse/JCR-3207>

> ...

Best regards, Julian

Mime
View raw message