-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: best practices question
PostPosted: Sun Jul 10, 2005 4:04 pm 
Newbie

Joined: Wed May 18, 2005 3:02 pm
Posts: 18
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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 10, 2005 4:22 pm 
Beginner
Beginner

Joined: Fri Jul 08, 2005 12:38 pm
Posts: 41
Location: Massachusetts, USA
The typical pattern for one-to-many is this:


Code:
class ParentObject {
   private Set children = new HashSet();

   public Set getChildren() { return this.children; }
   public void setChildren(Set children) { this.children = children; }

   public void addChild(ChildObject child) {
      child.setParent(this); // child has a many-to-one to parent
      this.children.add(child);
   }
}


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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 10, 2005 4:47 pm 
Newbie

Joined: Wed May 18, 2005 3:02 pm
Posts: 18
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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 10, 2005 4:48 pm 
Newbie

Joined: Wed May 18, 2005 3:02 pm
Posts: 18
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.