ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <larry.mead...@gmail.com>
Subject Re: Avoiding N+1 selects with more complex graphs
Date Thu, 23 Jun 2005 15:17:32 GMT
You would use groupBy="customerID,contactTypeID" in that case.

On 6/23/05, Aaron Craven <hibernate@vickerscraven.net> wrote:
> 
> Wonderful!
> 
> So, using the example below, I would simply add a groupBy to my resultMap for Customer
(say groupBy="customerID"), and one to my resultMap for Contact (say groupBy="contactID"),
correct?
> 
> One more question: what if Contact used a compound key? That is, suppose the key for
a Contact in the DB is [customerID, contactTypeID].  What would I use for my groupBy setting
on Contact?
> 
> Thanks!
> 
> ---------- Original Message ----------------------------------
> From: Clinton Begin <clinton.begin@gmail.com>
> Reply-To: cbegin@ibatis.com
> Date:  Wed, 22 Jun 2005 22:41:50 -0600
> 
> >There's no limit. You can go as wide or deep as you like. You can load any
> >graph of practical limit (i.e. ridiculous graphs won't likely perform well).
> >But certainly this is possible. The unit test actually uses a three tier
> >nesting.
> >
> >Cheers,
> >Clinton
> >
> >
> >On 6/22/05, Aaron Craven <hibernate@vickerscraven.net> wrote:
> >>
> >>
> >> I cannot decide if I've missed something in the documentation, or if I'm
> >> just plain old confused, but either way I need some help. With iBATIS 2, I
> >> realize the N+1 selects problem has been solved by the addition of the
> >> groupBy property. However, I'm a bit confused as to how this would be done
> >> with a deeper object graph. For example, suppose I have:
> >>
> >> - A Mapping that retrieves a number (M) of customers. Each customer has,
> >> in turn
> >> - A number (N) of contacts. Each contact, then has
> >> - A number (P) of addresses.
> >>
> >> Which would represent a… M:N:P relationship :)
> >>
> >> If I want this all in one mapping (something like CUSTOMER INNER JOIN
> >> CONTACTS ON (…) INNER JOIN ADDRESSES ON (…)), would it be possible, or is
> >> the depth of the join limited to one level of nesting?
> >>
> >> Thanks!
> >>
> >>
> >>
> >>
> >> ________________________________________________________________
> >> Sent via the WebMail system at vickerscraven.net<http://vickerscraven.net>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 
> 
> 
> 
> 
> ________________________________________________________________
> Sent via the WebMail system at vickerscraven.net
> 
> 
> 
> 
> 
>
Mime
View raw message