jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Inconsistent behavior upon moving nodes
Date Thu, 07 Feb 2013 13:06:54 GMT
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

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<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