ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MCCORMICK, Paul" <Paul.McCORM...@doir.wa.gov.au>
Subject RE: One query populating *multiple* lists per object returned
Date Mon, 15 May 2006 02:41:26 GMT

>>Thanks Jeff for your comments. Makes perfect sense. I forgot about
using a custom List Implementation approach. >>That would work out

How would you inject your custom list implementation?  Is thought ibatis
created the list implementation and did not provide the ability to
override it.

For example, if the Person was defined like below would ibatis create a
MyListImp object instead of its own List implementation?

Person Object
MyListImp cats;
MyListImp dogs;
int personID;
String personName;

-----Original Message-----
From: Rick Reumann [mailto:rickcr@gmail.com]
Sent: Friday, 12 May 2006 8:17 AM
To: user-java@ibatis.apache.org
Subject: Re: One query populating *multiple* lists per object returned

Jeff Butler wrote:
> It's not really a stupid question.  The problem is that adding the Dog

> table to the join list will, in effect, create a cross join between
> dog and cat - causing lots of data to be repeated as you've seen.
> There's not a great solution that I can think of.  One solution would
> be to use the iBATIS group by solution and a join for one of the lists
> (cats) - as you've already accomplished.  For the other list (dogs),
> you can populate it with a second query sort of like this:
> <resultMap id="personMap" class="foo.bar.Person" groupBy="personID">
>   <result property="personID"                  column="personID"/>
>   <result property="personName"             column="personName" />
>   <result property="cats"       resultMap="Persons.catsMap"/>
>   <result property="dogs" column="personId"
> </resultMap>
> I haven't tried this for real, but I think it will work.  This is
> still an N+1 query, but at least it's not 2N+1!
> Another thought is that you could write your own List implementation
> that would not allow duplicates.  Then it could all be done in one
> query because you would catch and throw out the duplicates in Java
> code.  As I think about it, I might like this solution better. 
> There's still a bunch of duplicate data coming back from the DB, but
> there's only on DB call.

Thanks Jeff for your comments. Makes perfect sense. I forgot about using
a custom List Implementation approach. That would work out nicely.


"DISCLAIMER: This email, including any attachments, is intended only for use by the addressee(s)
and may contain confidential and/or personal information and may also be the subject of legal
privilege. If you are not the intended recipient, you must not disclose or use the information
contained in it. In this case, please let me know by return email, delete the message permanently
from your system and destroy any copies.

Before you take any action based upon advice and/or information contained in this email you
should carefully consider the advice and information and consider obtaining relevant independent

View raw message