jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yoav Landman <yland...@gmail.com>
Subject Re: Understanding mixins merge logic
Date Tue, 28 Apr 2009 00:10:43 GMT

Well, I found a good discussion about the underlying logic in
https://issues.apache.org/jira/browse/JCR-2011 :)
However, in my case, none of the tx changed the mixins that are applied to
the node in question. So, does that mean that any concurrent changes to a
node that has mixins on it are deemed as conflicting? Isn't that a bit too
harsh or am I missing something?

Yoav  Landman wrote:
> Hi,
> I am trying to understand the logic of merging mixing changes -
> I see that the NodeStateMerger is failing a merge due do a difference in
> the mixin type names. In practice, however, the content of the mixin type
> namesets is identical between the overlayed state and the modified state
> (same *names* references). But since the comparison of the 2 namesets
> themselves is done by reference (NameSet does not override equals()) and
> since the *namesets* references are different the merge ends up with a
> StaleItemStateException.
> My question is -
> Shouldn't the comparison of the mixin type sets be done by content, not by
> the references of the namesets themselves? The relevant comments in
> NodeStateMerger say:
> "the mixins have been modified but by just looking at the diff we can't
> determine where the change happened since the diffs of either removing a
> mixin from the overlayed or adding a mixin to the transient state would
> look identical..."
> I am trying to understand this and how it applies to the current behavior,
> but can't. Could someone shed some light on it?
> Thanks,
> Yoav

View this message in context: http://www.nabble.com/Understanding-mixins-merge-logic-tp23267598p23267777.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

View raw message