The coolest thing... this test passes in iBATIS 3... no changes, it just worked.
Clinton On Thu, Aug 14, 2008 at 12:44 PM, Jeff Butler <[EMAIL PROTECTED]> wrote: > That's the general idea. I'm not sure of the merits of it or not. The pro > is that you could fill out a graph with one query. The con is that you end > up with a cross join and generate a ton of duplicate data coming back. > > The wierd thing is - sometimes this works, and sometimes it fails. I > haven't dug into it to see what the issue is, but here's a simple test case > that fails. All you need is iBATIS and HSQLDB to run it. > > Jeff Butler > > > > > On Thu, Aug 14, 2008 at 12:07 AM, Clinton Begin <[EMAIL PROTECTED]>wrote: > >> Couple of notes... >> >> * The top level call was for a list of categories (not just one). >> >> * I adapted this test from an existing test where categories had many >> products, which in turn had many items. >> >> So that would seem to be almost all of the possible cases... combinations >> of those should work, but I'd have to dream up quite a model to even come up >> with one. :-) >> >> Category >> - Items >> - Products >> >> ....or.... >> >> >> Category >> - Products >> - Items >> >> Clinton >> >> >> On Wed, Aug 13, 2008 at 11:04 PM, Clinton Begin <[EMAIL PROTECTED]>wrote: >> >>> I just wrote a little unit test for that. It totally works. Here's the >>> ResultMap to make sure we're talking about the same thing.... >>> >>> <resultMap id="categoryResultMap" class="testdomain.Category" >>> groupBy="categoryId"> >>> <result property="categoryId" column="catid"/> >>> <result property="name" column="catname"/> >>> <result property="description" column="catdescn"/> >>> * <result property="productList" resultMap="productResultMap"/> >>> <result property="itemList" resultMap="itemResultMap"/>* >>> </resultMap> >>> >>> <resultMap id="productResultMap" class="testdomain.Product" > >>> <result property="productId" column="productid"/> >>> <result property="categoryId" column="category"/> >>> <result property="name" column="prodname"/> >>> <result property="description" column="proddescn"/> >>> </resultMap> >>> >>> <resultMap id="itemResultMap" class="testdomain.Item"> >>> <result property="itemId" column="itemid"/> >>> <result property="productId" column="productid"/> >>> <result property="listPrice" column="listprice"/> >>> <result property="unitCost" column="unitcost"/> >>> <result property="supplierId" column="supplier"/> >>> <result property="status" column="status"/> >>> <result property="attribute1" column="attr1"/> >>> <result property="quantity" column="qty"/> >>> </resultMap> >>> >>> >>> >>> Clinton >>> >>> >>> On Wed, Aug 13, 2008 at 10:17 PM, Larry Meadors <[EMAIL PROTECTED] >>> > wrote: >>> >>>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <[EMAIL PROTECTED]> >>>> wrote: >>>> > 4. groupBy is gone completely. The <collection> element combined >>>> with the >>>> > ID element now work together to achieve this. I agree the old >>>> > implementation was annoying. What do you mean by multiple independent >>>> > lists? Does that not work now? >>>> >>>> I *think* he's referring to something like where you have people that >>>> have cats and dogs. >>>> >>>> Say you have a PERSON table, a DOG table, and a CAT table. >>>> >>>> If DOG has a person_id and CAT has a person_id, and you join the three >>>> tables, you can't get a list of person objects each with the correct >>>> list of dog and cat objects. >>>> >>>> I've not really understood the desire for this one, because you can't >>>> really do that effectively with SQL, either - so instead of 1+N >>>> selects, you do one select that returns m*n*o records. So for 10 >>>> people with 10 dogs and 10 cats, you get 1000 records instead of the >>>> 200 that 1+N selects get you. >>>> >>>> Rick has whined about that one for years. ;-) >>>> >>>> Larry >>>> >>> >>> >> >
