jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Inconsistent behavior upon moving nodes (was: Re: When moving a Tree, can it die?)
Date Wed, 06 Feb 2013 20:43:08 GMT

On Wed, Feb 6, 2013 at 8:04 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
> They are easy to fix but very difficult to detect and diagnose. No exception is thrown,
> just the behavior is unexpected. I think this is quite dangerous, since the spec is
> IMO quite clear about this
> http://www.day.com/specs/jcr/2.0/10_Writing.html#10.11.7%20Reflecting%20Item%20State

That's not as straightforward as it sounds. For example, consider the
following sequence:

    Node a = session.getNode("/foo");
    String id = a.getIdentifier();

    session.move("/foo", "/bar");

    Node b = session.getNodeByIdentifier(id);
    assert a.isSame(b); // ???

Should the last assertion pass or not? Interestingly it passes with
both Jackrabbit 2.x and Oak, even though they return different values
for b.getPath(). They're both correct!

According to sections 10.11.7 and 10.11.4, item identity in such cases
is determined by the item identifier, which means that a.isSame(b)
should always be true. Thus, for implementations like Oak, that use
the item path (up to root or the first referenceable ancestor) as the
identifier of non-referenceable nodes, the effect of the above move()
call should therefore be as if a.remove() had been called as otherwise
the identity of a would change. As a consequence, b.getPath() should
return "/foo". In Jackrabbit 2.x, where each node has a unique
non-path identifier, the move() call would change the path of a and
result in b.getPath() returning "/bar".

The above rationale would imply that in Oak is to make sure that all
session refreshes and transient moves should trigger re-evaluation of
the the paths of referenceable nodes and those with a referenceable
ancestor. Other nodes should keep behaving as they currently do.


Jukka Zitting

View raw message