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<[email protected]> 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
