in addition we still have an open TODO that the identifier
of a non-referenceable node should be as stable as possible
which means that it should include the identifier of the
parent... in other words: if one of the parent was referenceable
the identifier should be somehow combine uuid + relative path.
see https://issues.apache.org/jira/browse/OAK-101
kind regards
angela
On 2/7/13 1:05 PM, Michael Dürig wrote:
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.
Michael
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<[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
