hi jan
On Mon, May 19, 2014 at 11:07 PM, Jan Haderka <[email protected]> wrote: > > Hi, > I just wanted to double check that this is actually correct behaviour (as it > doesn’t seem to me that way). > > Consider following 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” > > I understand that from a repo point of view, move didn’t happen as it was not > persisted yet. But I’m working in single session and in that session I did > move, so my “local” view should be consistent. Or am I wrong? > > 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. > > 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()); > > This is tested with Jackrabbit 2.6.4 > > Thx for info/explanation of the behaviour. this is a bug. it's probably related to JCR-3239 and JCR-3368. BTW: the problem only occurs when modifying the root node. it's most likely caused by a bug in CachingHierarchyManager which caches the root node state. could you please file an issue? cheers stefan > > Jan Haderka / Magnolia Czech Republic > > > Magnolia > Chobot 1578, 76701 Kromeříž, Česká Republika > Tel: +420 571 118 715 www.magnolia-cms.cz > > > Attend Magnolia Worldwide User Conference June 24-26th, 2014 >
