I'm new to hibernate, but I've been cranking along with some success. However, I have a question that is more about style than substance.

When dealing with bi-directional associations, how do folks go about sorting out automatically populating both sides of the association when one side gets assigned to. Both 'Hibernate in Action' and the hibernate documentation mention doing so, but only provide examples for trivially simple cases. In my app, I have more complicated relationships, and I find myself getting into sitations where I can set up loops of assignment and containment. They are easy enough to detect and fix, but I am struggling to define a 'policy' that I can apply in every case which will prevent the problem from occuring in the first place. I was considering only doing the reverse assignment from the side which doesn't have the 'inverse' description in the metadata, but I found it harder than expected to really get it right. Things got really complicated when dealing with removal, too. All my getter and setter methods were getting very complicated.

Am I missing something obvious about this problem, or do I just need to apply a fair amount of thought, in every case, before setting up automatic inverse relationship assignment? I've tried removing all the extra assignment from the property get/set methods, and only including inverse relationship assignment in helper methods, so that the helper methods can call get/set methods without worrying about setting up chains of assignment that loop indefinitely. That seems like the best tactic so far. It is easiest to keep straight in my head what effect calling a method will have. This will be REALLY beneficial in a year, when I can no longer remember what I did in each case.

I'd appreciate the groups thoughts on this one. Thanks.

--sam

The typical pattern for one-to-many is this:




I assume this is what you mean by a "trivially simple case". It's not significantly more work to handle many-to-many relationships, which are the most complex association type that I'm aware of.

It's not clear to me what your relationships look like, so it's hard to take a swing at the problem.

That's what I have settled on, too. The getter and setter methods are kept simple.

An approximation of my model is this:

A user can own a collection, which is composed of items. Items have an owner, which can be different from the owner of the collection. Items are also heirarchical, so an item has a parent which is also an item (or null, at the root). A collection contains only a single heirarchy. So, the objects look approximately like this:

user
collections - all collections OWNED by user
items - all items OWNED by user

collection
owner
items - ALL items contained by collection
rootItem - item at top of heirarchy

items
owner
children - immediate child items
parent - parent item - inverse of children
collection - the collection which contains this item


Setting a new parent of an item has to update the item, the parent and potentially updates the collection, but the problem occurs everywhere. It is actually more complicated than above, but hopefully you get my drift. The problem is tracking changees that ripple through many objects, sometimes making a loop, so I have to do checking to ensure that an association hasn't already occured, rather than relying upon Set semantics to allow me to assign without bothering to check. I tried adding logic to the set and get methods themselves, but the complexity got evil. I had already moved the logic only to the add methods, and that simplified my life considerably. Many to many associations still require a check, since there is an add on both sides, but those are far fewer.

--sam

Argh. Th first line of each of the object descriptions above is just the name of the object. My inenting got dropped. I should have used a code block.

--sam