Hi, 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. 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. 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
