jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: When moving a Tree, can it die?
Date Tue, 23 Oct 2012 14:31:11 GMT
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