jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3 microkernel] Change log consolidation
Date Mon, 06 Feb 2012 13:38:26 GMT

On 6.2.12 13:27, Jukka Zitting wrote:
> On Mon, Feb 6, 2012 at 1:53 PM, Michael Dürig<mduerig@apache.org>  wrote:
>>> An alternative that AFAICT achieves the same effect in perhaps an
>>> easier to understand manner would be to use the state of the content
>>> tree instead of changes to that state as the key concept. [...]
>> That's more or less what I started with [1] and what I referred to as can of
>> worms in my original mail. Detecting and normalizing/consolidating moves
>> turned out to be too tricky there. You basically have the same cases I
>> identified (1. - 16.) but its much more difficult to tell them apart.
> 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).

I considered this but didn't really follow that approach since I wanted 
to be as independent from the persisted base as possible.
It might well be a working approach and it might have its own advantages 
but I doubt it will be simpler than my approach. Even with that approach 
there are many cases to consider many of which are edge cases.


> BR,
> Jukka Zitting

View raw message