Child nodes and references

[bwallis42]

I'm working on a design for storage of a tree of nodes that has a very simple structure. Essentially there is a root node that contains folders and each folder can contain either document nodes or other folders (usually not both). The second level of folders only contains document nodes so the hierarchy is limited to two levels. The document nodes can contain more structure but this is not relevant here.

I need to provide the ability to merge two trees together and then, later, maybe unmerge them again. The tree that is merged in needs to be retained in something like its original form to enable the unmerge or we need to keep sufficient information to be able to recreate it again later.

My first thought was to use JCR references. I update the node tree that I am merging into to include references to the folders and documents that are in the tree I am merging from. I've attached a diagram of what I would end up with assuming that I keep the node trees that I merged from under the main (merged to) node. So the operation was to merge the Patient_m1 node into the Patient1 node. In this example the Patient_m1 node has had a prior merge operation performed where the Patient_m2 node was merged into Patient_m1.

The example shown here leaves the original node trees untouched (apart from moving them) and inserts references to the document and episode nodes to enable a single complete view of the merged record.

The problem is that references just don't work like that. They are properties, not child nodes. So to reference all of the documents in a section I would need to call both getNodes() and getProperties() and then I would need to de-reference all of the properties and add the resultant node references to the list of nodes I got from getNodes().

From my limited point of view here, references seem to be a RRPITA! I would much rather have something like a unix filesystem link or symlink as the equivalent to the REFERENCE and WEAKREFERENCE but they just don't seem to work that way. This makes them much less useful than I first thought.

Have I understood JCR references correctly? Is there a better way to do this? My other thought was to move the nodes into the main tree and have references in the merged from trees. Unmerge is more complicated but doable.

[rhauch]

Have you looked at JCR's sharable nodes?

[bwallis42]

Ahha! I thought I must have missed something here. Shareable nodes look like just what I need.

Thanks again.

brian...

[bwallis42]

Will shared nodes pose some challenges in the federation implementation?

When we discussed this earlier I think we came to the conclusion that some metadata on a node (via a federation mixin) would influence the federation choice of connector and if a  child node doesn't have this metadata then it would inherit the federation behaviour from its parent node and be directed to a connector accordingly.

Unfortunatly a shared node has more than one parent. There is the concept of a deemed path but that seems to be somewhat loosely defined and is not particularly useful.

Just something that needs to be considered in the design I suppose.

[rhauch]

There still is a notion of a primary parent for the shareable nodes, and in ModeShape 2 that was the location of the node before it was shared. (If the shareable node is removed from that location, then the parent of the first shared location is used. If that's removed, then the parent of the next shared location is used, and so on).

I think we can deal with it. Like you said, it's just something we need to consider.