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 When moving a Tree, can it die?
Date Thu, 04 Oct 2012 15:34:34 GMT
Hi,

I was looking at ways to get rid of the weak child references we
currently have in TreeImpl. With the new state-tracking code we have
in NodeBuilder it should be possible to just create fresh new TreeImpl
instances whenever child nodes are accessed, and let the underlying
NodeBuilders handle the visibility of changes across those Tree
instances.

However, one thing that the NodeBuilders won't and can't handle is the
path or location information of a given node or tree, basically since
the NodeBuilder and NodeState interfaces intentionally have no
externally visible concept of a "parent node" or even of a "path".

Normally this isn't a problem as long as trees are not moved around,
as their parent and location information will just remain the same
from the time when they were instantiated. But when a tree *is* moved,
the only easy way to make the affected Tree instances reflect such
changes is if we have (weak) references to all those instances -
something that would be nice to be able to avoid.

To illustrate the problem, here's a code snippet adapted from the
RootImpl.move2 test that fails if we drop the weak child references
from TreeImpl:

        Tree r = root.getTree("/");
        Tree x = r.getChild("x");
        Tree y = r.getChild("y");

        root.move("/x", "/y/x");
        assertEquals("y", x.getParent().getName());

To avoid this problem, I'm wondering if we could allow a Tree instance
that was acquired before the move to become invalid or "disconnected"?
Any changes to a Tree instance in such a sate would just be discarded
and the return values of methods like getParent() or getLocation()
would be undefined (typically returning the values they had before the
move).

BR,

Jukka Zitting

Mime
View raw message