Bidirectional associations and circular references

[Eric Blue <er...@gmail.com>]

Hi,

I apoligize in advance if this problem has been addressed previously on this 
list. But, I've come across a (more than likely) common situation where I 
have 2 Objects:

Object 1 has a m:n relationship to Object2
AND
Object 2 has a 1:1 relationship to Object1

In other words, Object1.getObject2List() returns a collection of Object2. 
And Object2.getObject1() returns a single instance of Object1. I quickly 
discovered the circular relationship problem and noticed the disclaimer in 
the SQLMaps doc Pg. 30.

Important! Currently the SQL Map framework does not automatically resolve 
circular relationships. Be
aware of this when implementing parent/child relationships (trees). An easy 
workaround is to simply define
a second result map for one of the cases that does not load the parent 
object (or vice versa), or use a join as
described in the "N+1 avoidance" solutions.

I did what the doc advised, and for Object1 (which fetches the collection of 
Object2) I simply made a "noParent" resultmap which excluded itself. This 
works fine for now, but I'm curious if there are any other approaches. And, 
wondering if this will be addressed in the near future.

Thanks!

P.S. iBATIS still rocks ;)

Re: Bidirectional associations and circular references

[Eric Blue <er...@gmail.com>]

Hi Larry,

You're right, this is a Order to OrderItem relationship (I should have used 
a more practical example). To be honest, for our initial release we could do 
away with resolving the 1:1 relationship, so this is just a nice-to-have 
right now. 

Currently, our object model/business objects are very hierarchical in nature 
(going as deep as 4 levels). Our service layer allows basic CRUD on all of 
these objects. In most cases, traversal of the object graph will be top to 
bottom. However, in some cases we want to be able to quickly resolve the 
parent or grand-parent of the object.

Client-side our controller could maintain state for IDs so lookups could 
happen there, but it would be ideal if we could avoid this. And, I also 
thought about your suggestion for doing this at the DAO layer. But, the 
extra result map does work for now so I guess we can deal with that. It 
would be nice if this was completely transparent. But, I'm not certain how 
much work this would translate into.



On 8/9/05, Larry Meadors <la...@gmail.com> wrote:
> 
> Hm, I am assuming this is something like an Order to OrderItem 
> relationship.
> 
> I'll try not to preach too much about this, but I generally shy away
> from these kinds of relationships, because they are rarely all that
> valuable.
> 
> You could do this with a RowHandler by joining Order+OrderItem into a
> composite object (with an Order and an OrderItem in it).
> 
> Probably the easier way is in you DAO class, get the Order object,
> then get the OrderItem objects, then iterate through the OrderItem
> objects and set the Order on them to the parent. Not real elegant, but
> effective.
> 
> Just curious: Why do you need this relationship in your objects?
> 
> Larry
> 
> 
> On 8/9/05, Eric Blue <er...@gmail.com> wrote:
> > Hi,
> >
> > I apoligize in advance if this problem has been addressed previously on
> > this list. But, I've come across a (more than likely) common situation
> > where I have 2 Objects:
> >
> > Object 1 has a m:n relationship to Object2
> > AND
> > Object 2 has a 1:1 relationship to Object1
> >
> > In other words, Object1.getObject2List() returns a collection of 
> Object2.
> > And Object2.getObject1() returns a single instance of Object1. I quickly
> > discovered the circular relationship problem and noticed the disclaimer 
> in
> > the SQLMaps doc Pg. 30.
> >
> > Important! Currently the SQL Map framework does not automatically 
> resolve
> > circular relationships. Be
> > aware of this when implementing parent/child relationships (trees). An 
> easy
> > workaround is to simply define
> > a second result map for one of the cases that does not load the parent
> > object (or vice versa), or use a join as
> > described in the "N+1 avoidance" solutions.
> >
> > I did what the doc advised, and for Object1 (which fetches the 
> collection
> > of Object2) I simply made a "noParent" resultmap which excluded itself.
> > This works fine for now, but I'm curious if there are any other 
> approaches.
> > And, wondering if this will be addressed in the near future.
> >
> > Thanks!
> >
> > P.S. iBATIS still rocks ;)
> >
> >
>

Re: Bidirectional associations and circular references

[Larry Meadors <la...@gmail.com>]

Hm, I am assuming this is something like an Order to OrderItem relationship.

I'll try not to preach too much about this, but I generally shy away
from these kinds of relationships, because they are rarely all that
valuable.

You could do this with a RowHandler by joining Order+OrderItem into a
composite object (with an Order and an OrderItem in it).

Probably the easier way is in you DAO class, get the Order object,
then get the OrderItem objects, then iterate through the OrderItem
objects and set the Order on them to the parent. Not real elegant, but
effective.

Just curious: Why do you need this relationship in your objects?

Larry


On 8/9/05, Eric Blue <er...@gmail.com> wrote:
> Hi,
>  
>  I apoligize in advance if this problem has been addressed previously on
> this list.  But, I've come across a (more than likely) common situation
> where I have 2 Objects:
>  
>  Object 1 has a m:n relationship to Object2
>  AND
>  Object 2 has a 1:1 relationship to Object1
>  
>  In other words, Object1.getObject2List() returns a collection of Object2. 
> And Object2.getObject1() returns a single instance of Object1.  I quickly
> discovered the circular relationship problem and noticed the disclaimer in
> the SQLMaps doc Pg. 30.
>  
>  Important! Currently the SQL Map framework does not automatically resolve
> circular relationships. Be
>  aware of this when implementing parent/child relationships (trees). An easy
> workaround is to simply define
>  a second result map for one of the cases that does not load the parent
> object (or vice versa), or use a join as
>  described in the "N+1 avoidance" solutions.
>  
>  I did what the doc advised, and for Object1 (which fetches the collection
> of Object2) I simply made a "noParent" resultmap which excluded itself. 
> This works fine for now, but I'm curious if there are any other approaches. 
> And, wondering if this will be addressed in the near future.
>  
>  Thanks!
>  
>  P.S. iBATIS still rocks ;)
>  
>