Hello, I am hoping someone can give me a hint on sound design for the following scenario, for storing a tree associated with a given user. I have pawed through the manual, faq and examples but not found anything completely pertinent to this scenario:

class User
rootNode ---> Node (not-null)

class Node
parent ---> Node (this is null for a root node only)
owner ---> User (not-null)
set children --> Node

The problem is how to set up these relationships in Hibernate

I am totally new to ORM, and the solutions I can think of make me uncomfortable

(1) make User.rootNode and Node.owner many-to-one connections. This makes it impossible to save anything to the database, unless one of the not-nulls is dropped, and adding a new user + tree then entails add one, add the other, update the first (yuck).

(2) Use one-to-one bidirectional associations to allow hibernate to cope with the not-null constraints. This won't work for rootNode<->owner since node.owner.rootNode != node in general. This seems to indicate that two separate bidirectional associations would be needed, User.rootNode <-one-to-one-> Node.isRootToUser, and (set) User.allNodes <-one-to-many-> Node.owner. This seems like overkill since we don't actually use these new entries (isRootToUser and allNodes) except to make the persisting work properly. Then again it is rather obvious that the second association is redundant, one could always do away with User.allNodes and Node.owner, and get all Nodes of a User via its User.rootNode and Node.children, and the owner of a Node via Node.parent and Node.isRootNodeToUser. On the one hand this sounds nice since it avoids potential inconsistency errors, on the other hand a bit of redundancy would help with error recovery. It also means that to find out who owns a particular node you have to read in a large fraction of the tree (sounds inefficient, ?).

So I don't know, interested to hear from people more used to thinking about these things before I commit myself too deeply to a particular design.