jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Inconsistent behavior upon moving nodes (was: Re: When moving a Tree, can it die?)
Date Tue, 05 Feb 2013 16:20:40 GMT
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