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 <[email protected]>wrote: > Hi, > > On Wed, Feb 6, 2013 at 8:04 PM, Marcel Reutegger <[email protected]> > 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 >
