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:18:11 GMT
On Mon, Feb 6, 2012 at 3:10 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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>

agreed, but personally i don't consider this a real world use case.

cheers
stefan

>
>> ...
>
>
> Best regards, Julian

Mime
View raw message