ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Craven" <hibern...@vickerscraven.net>
Subject Re: Avoiding N+1 selects with more complex graphs
Date Thu, 23 Jun 2005 15:47:17 GMT

Okay, many thanks to everyone for their help!

---------- Original Message ----------------------------------
From: Larry Meadors <larry.meadors@gmail.com>
Reply-To: lmeadors@apache.org
Date:  Thu, 23 Jun 2005 09:17:32 -0600

>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
>> 
>> 
>> 
>> 
>> 
>>
>
 




________________________________________________________________
Sent via the WebMail system at vickerscraven.net


 
                   


Mime
View raw message