Hi, On Fri, Oct 19, 2012 at 11:40 PM, Jukka Zitting <jukka.zitt...@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
