Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <525D5ACD.7010503@apache.org>
Date: Tue, 15 Oct 2013 17:10:05 +0200
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: CommitHook not detecting new items
References: <CE832029.A92E%anchela@adobe.com>
In-Reply-To: <CE832029.A92E%anchela@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


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" <anchela@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
>>
>