Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 74.125.82.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F2FCD4B.6090002@apache.org>
References: <4F2C2B0E.7050508@apache.org>
 <CAOFYJNbnz5UybLwpQyz6xtjps5cDXQbLQAiftF5KqeLMM+9Z1w@mail.gmail.com>
 <4F2FCD4B.6090002@apache.org>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Mon, 6 Feb 2012 14:27:19 +0100
Message-ID: 
 <CAOFYJNZKq38dWaZe5fVzvvDZaHOQyf_nyARMue4inebk3bRdiw@mail.gmail.com>
Subject: Re: [jr3 microkernel] Change log consolidation
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Feb 6, 2012 at 1:53 PM, Michael D=FCrig <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).

BR,

Jukka Zitting