[
https://issues.apache.org/jira/browse/JCR-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Haderka updated JCR-3779:
-----------------------------
Description:
Consider following code:
{code}
session.getRootNode().addNode(“foo”);
session.save();
Node fooNode = session.getNode("/foo");
assertEquals("/foo", fooNode.getPath());
session.move("/foo", "/bar");
Node barNode = session.getNode("/bar");
assertEquals(“/bar”, barNode.getPath()); <== this line actually fails, because
barNode.getPath() still returns “/foo”
{code}
>From a repo point of view, move didn’t happen as it was not persisted yet. But
>the example above is working in single session and in that session move did
>happen, so “local” view should be consistent.
Now aside from the weirdness of the above code, there is also consistency
problem, because if I remove the save() call and run code like shown below, it
will actually pass, so getPath() after move will behave differently whether or
not was BEFORE the move persisted in the repo.
{code}
session.getRootNode().addNode(“foo”);
Node fooNode = session.getNode("/foo");
assertEquals("/foo", fooNode.getPath());
session.move("/foo", "/bar");
Node barNode = session.getNode("/bar");
assertEquals(“/bar”, barNode.getPath());
{code}
As per comment from Stefan Guggisberg, this happens only at the root node level
and is most likely caused by bug in {{CachingHierarchyManager}} and related to
JCR-3239 and JCR-3368.
was:
Consider following code:
{format}
session.getRootNode().addNode(“foo”);
session.save();
Node fooNode = session.getNode("/foo");
assertEquals("/foo", fooNode.getPath());
session.move("/foo", "/bar");
Node barNode = session.getNode("/bar");
assertEquals(“/bar”, barNode.getPath()); <== this line actually fails, because
barNode.getPath() still returns “/foo”
{format}
>From a repo point of view, move didn’t happen as it was not persisted yet. But
>the example above is working in single session and in that session move did
>happen, so “local” view should be consistent.
Now aside from the weirdness of the above code, there is also consistency
problem, because if I remove the save() call and run code like shown below, it
will actually pass, so getPath() after move will behave differently whether or
not was BEFORE the move persisted in the repo.
{format}
session.getRootNode().addNode(“foo”);
Node fooNode = session.getNode("/foo");
assertEquals("/foo", fooNode.getPath());
session.move("/foo", "/bar");
Node barNode = session.getNode("/bar");
assertEquals(“/bar”, barNode.getPath());
{format}
As per comment from Stefan Guggisberg, this happens only at the root node level
and is most likely caused by bug in {{CachingHierarchyManager}} and related to
JCR-3239 and JCR-3368.
> Node.getPath() returns inconsistent values depending on whether node is saved
> or not
> ------------------------------------------------------------------------------------
>
> Key: JCR-3779
> URL: https://issues.apache.org/jira/browse/JCR-3779
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.6.4
> Reporter: Jan Haderka
>
> Consider following code:
> {code}
> session.getRootNode().addNode(“foo”);
> session.save();
> Node fooNode = session.getNode("/foo");
> assertEquals("/foo", fooNode.getPath());
> session.move("/foo", "/bar");
> Node barNode = session.getNode("/bar");
> assertEquals(“/bar”, barNode.getPath()); <== this line actually fails,
> because barNode.getPath() still returns “/foo”
> {code}
> From a repo point of view, move didn’t happen as it was not persisted yet.
> But the example above is working in single session and in that session move
> did happen, so “local” view should be consistent.
> Now aside from the weirdness of the above code, there is also consistency
> problem, because if I remove the save() call and run code like shown below,
> it will actually pass, so getPath() after move will behave differently
> whether or not was BEFORE the move persisted in the repo.
> {code}
> session.getRootNode().addNode(“foo”);
> Node fooNode = session.getNode("/foo");
> assertEquals("/foo", fooNode.getPath());
> session.move("/foo", "/bar");
> Node barNode = session.getNode("/bar");
> assertEquals(“/bar”, barNode.getPath());
> {code}
> As per comment from Stefan Guggisberg, this happens only at the root node
> level and is most likely caused by bug in {{CachingHierarchyManager}} and
> related to JCR-3239 and JCR-3368.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
