On 6.2.12 13:27, Jukka Zitting wrote:
On Mon, Feb 6, 2012 at 1:53 PM, Michael Dürig<mdue...@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.
Michael
BR,
Jukka Zitting
