A ha! Need to explicitly set the owner on the belongs-to class, and also put it in the collection. I suspect because it’s marked as nullable:false.
But it’s plain wrong to save the owner if I have put stuff in the collection that can’t be saved. Hibernate invisibly does only half the job I asked it to do, potentially screwing up the data structure.
Ok. Now for the tree link. The top node of the tree – the TreeNode – is not actually the root of the tree. THe root of the tree is an invisible node below this, which potentially gets versioned. The reason this invisible node is invisible is that a “tree” is potentially a holder for a number of smaller trees that have no connection to each other, an example being a set of taxonomies at familiy level that make no attempt to assemble them into higher-order taxa.
Tree links belong to their supernode. To put it another way, a node *is* the content of its tree_node and its set of links to subnodes.There are three types:
- F – fixed links. A simple node to node link.
- T – tracking links. If the node is current, then when the subnode is replaced with a new node, the link is updated to point to that new node.
- V – versioning links. If the node is current, then when the subnode is replaced with a new node, a new node is created and this node is replaced by it.
The entire focus of the system is managing those versioning links – the algorithm is … interesting, because a goal of the system is to do versioning in batches in order to avoid spawning new nodes and ids for every little user action, and because our tree potentially contains diamonds (the structure may one day hold more than just a taxonomy – I think it will serve as a profile store).
In any event, a UserTree is linked by a tracking link to it’s invisible root node. As the user tree is edited and new versions checked in, the top tree node points to the new root.