jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Süß <dominik.su...@gmail.com>
Subject Re: Inconsistent behavior upon moving nodes (was: Re: When moving a Tree, can it die?)
Date Thu, 07 Feb 2013 08:04:05 GMT
Sorry for jumping in without having the overall picture.
Is it really a good idea to use the path as identifier? For Referencable
Identifiers (25.1) it is pretty clear that an ID is structureindepenent, so
why should a nonreferencable be bound to a path. Since a node can return
its path I do not see a reason why the identifier should be the same. I'd
assume that someone implementing on that base then would now that ID is
something reliable when having the "move" case, while path is really
something structurespecific. By a combination of both you can be sure to
handle the same entity.

Best regards

On Wed, Feb 6, 2013 at 9:43 PM, Jukka Zitting <jukka.zitting@gmail.com>wrote:

> Hi,
> 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");
>     session.getRootNode().addNode("foo");
>     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.
> BR,
> Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message