On Fri, Feb 3, 2012 at 7:44 PM, Michael Dürig<mdue...@apache.org> wrote:
While working on a new transient space implementation [1] I discovered that
recreating a list of changes from transient modifications to the hierarchy
is like opening a can of worms. Rethinking things it turned out, that it is
much simpler to directly consolidate the change log.
Sounds useful, especially for cases where potentially conflicting
changes need to be merged. The more we can simplify and/or normalize
changes, the easier merging them is.
Yes that's another reason I was working on this. We have the same
underlying problem with cluster sync, applying transient changes into
persistence space and refreshing persistent changes into the transient
space.
I wasn't thinking about merging based on (consolidated) change logs yet
but this is a very valid point!
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. Instead of a
commit(changeLog, baseState) method we could have a commit(newState,
baseState) method for persisting changes. The backend could then do a
diff between the two states, which should result in pretty much the
same list of changes as the proposed change log consolidation
mechanism. The only tricky part that I can think of is detecting moves
of non-referenceable nodes, but even that should be doable with hidden
UUIDs like what we already have in current Jackrabbit.
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.
Apart from that, I think there is really a value in having a stateless
algorithm. And it is really not too hard to understand ;-)
Michael
[1] http://markmail.org/message/qkkcvtmtapas2cx4
The nice thing about such state-based handling of changes is that the
transient space in any case needs to maintain a representation of the
state of the modified tree.
PS. You might already have discussed and dismissed this idea off-list.
If yes, what was the deal-breaker?
BR,
Jukka Zitting
