jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Inconsistent behavior upon moving nodes
Date Tue, 05 Feb 2013 16:39:33 GMT

Some background on this:

Tracking nodes across moves is troublesome. This is something which came 
already up in my internal prototype as early as late 2011. I mentioned 
this at our meeting in February 2012 and also that one way to handle 
this are weak references.

With the node builder approach in OAK-391 Jukka explored ways to get rid 
of weak references but came to the same conclusion: this won't work with 
moves.

Since we considered weak references to be worse than not being able to 
track nodes across moves, we dropped the support for the latter.


AFAICT we have three possibilities here:

1) drop support for tracking nodes across moves (AKA OAK-391),
2) track nodes through weak reference,
3) come up with another ingenious approach of tracking nodes across moves.

I'd be for 3) if someone can come up with something and 1) otherwise.

Michael


On 5.2.13 16:20, Angela Schreiber wrote:
> hi jukka
>
> i just learned that this discussion wasn't solely about the Tree's
> behavior upon move/rename but also affects the JCR Nodes.
>
> as stated in https://issues.apache.org/jira/browse/OAK-606
> and https://issues.apache.org/jira/browse/OAK-607
> the current behavior is IMO inconsistent between new and existing
> nodes and pretty strange from a JCR API consumer point of view.
>
> since i missed the fact that this discussion was about Nodes
> as well i would like to express my concerns and disagreement
> with what may have looked like lazy consensus.
>
> kind regards
> angela
>
> ps: i would appreciate if subjects could be kept up to date when
> extending the focus of the discussion.
>
>
> On 10/23/12 4:31 PM, Jukka Zitting wrote:
>> Hi,
>>
>> On Fri, Oct 19, 2012 at 11:40 PM, Jukka
>> Zitting<jukka.zitting@gmail.com>  wrote:
>>> The trouble is that a parent doesn't have a direct reference to a
>>> child and can thus not tell it that it has become invalid. The only
>>> way I can think of to solve this issue is for the child to ask the
>>> parent about the status whenever accessed, a bit like what
>>> MemoryNodeBuilder now does.
>>
>> In the past few MemoryNodeBuilder commits I came up with a mechanism
>> that covers this case even better.
>>
>> Basically the idea is that each builder is permanently tied to the
>> *path* from which it was acquired. If content is copied or moved
>> around, the builders used to access or modify the source tree still
>> refer to the old location even if it no longer exists (in which case
>> they'd throw IllegalStateExceptions when accessed). If other content
>> is added to replace previously removed content, then such builders
>> would automatically start reflecting the new content. In short, a
>> builder accessed at a given path will always behave as if it was a
>> fresh new builder acquired using that same path (with an ISE thrown if
>> the path doesn't exist).
>>
>> To make this behavior apply also to Trees in oak-core and Nodes in
>> oak-jcr, we'd need to change the semantics of TreeImpl and NodeImpl
>> similarly so that they'll always refer to content at the path for
>> which they were originally created. Operations like Root.move() or
>> Session.move() will not change the paths or parents of existing Tree
>> or Node *instances*, though they may well cause those instances to
>> become invalid (resulting in InvalidItemStateExceptions being thrown
>> when trying to access such nodes).
>>
>> Such a change will cause a few existing test cases to fail, but I
>> think in the big picture such change in behavior should be OK as
>> AFAICT there aren't that many clients that even use move() or, if they
>> do, depend on a specific behavior of existing Node instances across
>> the move.
>>
>> BR,
>>
>> Jukka Zitting

Mime
View raw message