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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ;)
>
>
