You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Angela Schreiber <an...@adobe.com> on 2013/10/15 15:45:24 UTC
CommitHook not detecting new items
hi all
once again i found myself struggling with the way the commit hooks
identify new items. in the example test below there is in fact a
new node being created.
nevertheless the commit hook (in this case the VersionablePathHook)
will not see a new jcr:versionhistory property but only the modification
of an existing one... which is at least a bit confusing as this
protected property can't be modified and there was in fact a new
node created which get's a new version history, a new uuid and so forth.
>@Test
> public void testVersionableChildNode2() throws Exception {
> Node testNode =
>superuser.getNode(path).addNode("n1").addNode("n2").addNode("n3").addNode(
>"
>jcr:content");
> testNode.addMixin("mix:versionable");
> superuser.save();
>
>
> testNode.remove();
> testNode =
>superuser.getNode(path).getNode("n1").getNode("n2").getNode("n3").addNode(
>"
>jcr:content");
> testNode.addMixin("mix:versionable");
> superuser.save(); // does NOT trigger
>VersionablePathHook#propertyAdded
>
> assertTrue(testNode.isNodeType("mix:versionable"));
> VersionHistory vh = testNode.getVersionHistory();
> Property versionablePath =
>vh.getProperty(superuser.getWorkspace().getName()); // FAILS with
>PathNotFoundException!
> assertEquals(testNode.getPath(), versionablePath.getString());
> }
i can work around this by looking for modified jcr:versionHistory
properties.
but to be honest this looks quite wrong to me :-)
kind regards
angela
Re: CommitHook not detecting new items
Posted by Michael Dürig <md...@apache.org>.
Hi,
On 15.10.13 4:44 , Angela Schreiber wrote:
> hi
>
> quick follow up: i just had a private discussion with michael in
> the office and he added that this is related to what we are
> struggling with when it comes to move in general and to move
> in combination with permissions.
It is related in the sense that we are "only" seeing a consolidated view
of changes instead of the detailed sequence of operations that led here.
>
> while moving non-referenceable nodes actually can be considered
> a deletion plus subsequent add as the node is no longer the 'same'
> in our oak setup (not every single node has an unique identifier
> as it was the case in jackrabbit-core), we definitely should take
> a second look at the move of referenceable nodes.
We can actually use this as an explanation (more like an excuse, that is
;-) ) for why there are no NODE_MOVED events. However, as Angela
mentions the situation is different for nodes that have a more stable
identifier than its path (i.e. referenceable nodes). Here we could
detect move operations as the identity of such nodes does not change
across moves.
This would allow us to correctly handle permission evaluation and to
generate NODE_MOVED events for moved nodes that are referenceable.
Not sure whether its worth the additional complexity though.
Michael
>
> wdyt, would this be a reasonable topic to look at and discuss for
> our october oakathon next week?
>
> kind regards
> angela
>
>
> On 10/15/13 3:45 PM, "Angela Schreiber" <an...@adobe.com> wrote:
>
>> hi all
>>
>> once again i found myself struggling with the way the commit hooks
>> identify new items. in the example test below there is in fact a
>> new node being created.
>>
>> nevertheless the commit hook (in this case the VersionablePathHook)
>> will not see a new jcr:versionhistory property but only the modification
>> of an existing one... which is at least a bit confusing as this
>> protected property can't be modified and there was in fact a new
>> node created which get's a new version history, a new uuid and so forth.
>>
>>> @Test
>>> public void testVersionableChildNode2() throws Exception {
>>> Node testNode =
>>> superuser.getNode(path).addNode("n1").addNode("n2").addNode("n3").addNode
>>> (
>>> "
>>> jcr:content");
>>> testNode.addMixin("mix:versionable");
>>> superuser.save();
>>>
>>>
>>> testNode.remove();
>>> testNode =
>>> superuser.getNode(path).getNode("n1").getNode("n2").getNode("n3").addNode
>>> (
>>> "
>>> jcr:content");
>>> testNode.addMixin("mix:versionable");
>>> superuser.save(); // does NOT trigger
>>> VersionablePathHook#propertyAdded
>>>
>>> assertTrue(testNode.isNodeType("mix:versionable"));
>>> VersionHistory vh = testNode.getVersionHistory();
>>> Property versionablePath =
>>> vh.getProperty(superuser.getWorkspace().getName()); // FAILS with
>>> PathNotFoundException!
>>> assertEquals(testNode.getPath(), versionablePath.getString());
>>> }
>>
>> i can work around this by looking for modified jcr:versionHistory
>> properties.
>> but to be honest this looks quite wrong to me :-)
>>
>> kind regards
>> angela
>>
>
Re: CommitHook not detecting new items
Posted by Angela Schreiber <an...@adobe.com>.
hi
quick follow up: i just had a private discussion with michael in
the office and he added that this is related to what we are
struggling with when it comes to move in general and to move
in combination with permissions.
while moving non-referenceable nodes actually can be considered
a deletion plus subsequent add as the node is no longer the 'same'
in our oak setup (not every single node has an unique identifier
as it was the case in jackrabbit-core), we definitely should take
a second look at the move of referenceable nodes.
wdyt, would this be a reasonable topic to look at and discuss for
our october oakathon next week?
kind regards
angela
On 10/15/13 3:45 PM, "Angela Schreiber" <an...@adobe.com> wrote:
>hi all
>
>once again i found myself struggling with the way the commit hooks
>identify new items. in the example test below there is in fact a
>new node being created.
>
>nevertheless the commit hook (in this case the VersionablePathHook)
>will not see a new jcr:versionhistory property but only the modification
>of an existing one... which is at least a bit confusing as this
>protected property can't be modified and there was in fact a new
>node created which get's a new version history, a new uuid and so forth.
>
>>@Test
>> public void testVersionableChildNode2() throws Exception {
>> Node testNode =
>>superuser.getNode(path).addNode("n1").addNode("n2").addNode("n3").addNode
>>(
>>"
>>jcr:content");
>> testNode.addMixin("mix:versionable");
>> superuser.save();
>>
>>
>> testNode.remove();
>> testNode =
>>superuser.getNode(path).getNode("n1").getNode("n2").getNode("n3").addNode
>>(
>>"
>>jcr:content");
>> testNode.addMixin("mix:versionable");
>> superuser.save(); // does NOT trigger
>>VersionablePathHook#propertyAdded
>>
>> assertTrue(testNode.isNodeType("mix:versionable"));
>> VersionHistory vh = testNode.getVersionHistory();
>> Property versionablePath =
>>vh.getProperty(superuser.getWorkspace().getName()); // FAILS with
>>PathNotFoundException!
>> assertEquals(testNode.getPath(), versionablePath.getString());
>> }
>
>i can work around this by looking for modified jcr:versionHistory
>properties.
>but to be honest this looks quite wrong to me :-)
>
>kind regards
>angela
>