On 21.10.13 8:23 , Michael Dürig wrote:
IIRC, in JR2 a moved node triggers 3 events: node added, node deleted
and node moved. but maybe I'm wrong, but I thought we kept this for
backward compatibility.
Thanks for the heads up. Will double check. This would in fact simplify
event generation in
Hi,
>IIRC, in JR2 a moved node triggers 3 events: node added, node deleted
>and node moved.
Cool, I didn't know this :-)
Regards,
Thomas
On 21.10.13 7:18 , Tobias Bocanegra wrote:
On Mon, Oct 21, 2013 at 7:31 AM, Thomas Mueller wrote:
>Hi,
>
>>extra pass
>
>On how to avoid this extra pass. Not strictly backward compatible, but I
>wonder how much it would break: what if observation would deliver two
>events for moved nodes: t
Hi,
> extra pass
On how to avoid this extra pass. Not strictly backward compatible, but I
wonder how much it would break: what if observation would deliver two
events for moved nodes: the "node moved" event (added at the target), plus
the "node deleted" event (deleted at the source)? The one use
Hi,
I implemented a very rough POC of the algorithm outlined below. See [1]
for the implementation itself. On move a node is annotated with its
source path in NodeBuilder.moveTo(). Later moves can be extracted
through the standalone MoveDetector class. See MoveDetectorTest for
details. MoveD
IMHO it's worth trying to get a solution for this.
if we do, i would suggest that we detect the move before
passing the information down to the commit hooks. in other
words, there should be a method like nodeMoved in order to prevent
that every move-sensitive hook has to write the same code in ord
Hi,
On Thu, Oct 17, 2013 at 8:16 AM, Michael Dürig wrote:
> To avoid the second pass, we could also remember the paths of the moved
> nodes in a global place (*).
Perhaps the new CommitInfo?
I assume we'd only need to track moves for local commits as that's
where permission evaluation is done,
>From the user point of view I think this makes sense and it'd be worth the
effort, also it looks like the global space approach would allow to do that
without loosing too much in terms of performance.
My 2 cents,
Tommaso
2013/10/17 Michael Dürig
>
> Hi,
>
> Currently we can't detect a move op
Hi,
Currently we can't detect a move operation through diffing node states.
Those operation are currently seen as separate remove and add operations
that can't be easily associated with each other. This impacts permission
evaluation (OAK-710, OAK-783) and observation (OAK-144, OAK-1090), whic
