jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Inconsistent behavior upon moving nodes
Date Thu, 07 Feb 2013 12:05:41 GMT

Hi Dominik,

This behaviour has been chosen as a trade off. The JCR specification 
explicitly allows for this. That is, the path might be the most stable 
identifier so this is what is returned for non referenceable nodes. 
Apart from that, the identifier is opaque and the fact that it resembles 
a path must not lead the client to use it as such.

For clients who need "more" stable identifiers, there is always the 
option of making nodes referenceable. This puts clients into control of 
trading off the additional overhead involved for the additional 
identifier stability.


On 7.2.13 8:04, Dominik Süß wrote:
> 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
> Dominik
> 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

View raw message