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 13:48:57 GMT
On Mon, Feb 6, 2012 at 2:27 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> 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).

BTW, that's how it the transient space is implemented in the current
jackrabbit-core.

cheers
stefan

>
> BR,
>
> Jukka Zitting

Mime
View raw message