file a JIRA issue on that and we'll update the docs. Thanks for your insight on this.
Brandon On 6/8/05, Ersin Er <[EMAIL PROTECTED]> wrote: > The main problem with the developer guide for Complex List Properties > section was > > 1) The example uses groupBy attribute value as the table column name > which is same as class property. I thought its value comes from table > column. It the table column's and class property's names were different > it would be much more easier to understand. > 2) The example query was also a groupBy query. So I thought that groupBy > attribute in the mapping xml has some relation with the query itself. > > I think these are important points that makes the document hard to > understand for a newbea. > > Cheers, > Ersin > > Ersin Er wrote: > > > Hi, > > > > Thanks for the detailed reply. Today, I have implemented a similar > > example and understood the concept. I've realized that groupBy > > attribute take the related key from the "class property", not db table > > column. When I've tried the table column as the value of the groupBy, > > it worked without any exeptions but with silly results. Every row was > > mapped with a category, however there were 9 rows and 3 categories. > > Isn't it possible for SQL Mapper to determine if the value of the > > groupBy really maps with an existing property? > > > > By the last example everything (ofcourse in the context of groupBy :) > > ) became more clear. > > > > And one more question. As I see, you prefer to put a product list to > > category class, but you do not prefer to put a category reference to > > product class. Is this the prefered way to implement this kind of > > relationships especially where circular dependencies exist? > > > > Thanks. > > > > -- Ersin > > > > Brandon Goodin wrote: > > > >> The real issue that is addressed with the groupBy is the ability to > >> use a single query for populating complex properties mapped in the > >> resultMap with the <result...resultMap="..."/> tag. In the past you > >> would be required to map to a statement with the select attribute of > >> the result tag which meant multiple additional queries and redundant > >> object population. There were other strategies that were just as > >> inneficient. The groupBy eliminates this by allowing you to specify > >> the repeating property that will identify this object and populate the > >> class defined in the resultMap. Further you can chain multiple > >> resultMaps using the <result...resultMap="..."/> tag and map any > >> number of objects with groupBy using the same select results. > >> > >> Following is a sample Clinton posted from the unit tests a while back. > >> It may help you to understand groupBy better: > >> > >> <resultMap id="categoryResult" class="testdomain.Category" > >> groupBy="categoryId"> > >> <result property="categoryId" column="catid"/> > >> <result property="name" column="name"/> > >> <result property="description" column="descn"/> > >> <result property="productList" resultMap="productResult"/> > >> </resultMap> > >> > >> <resultMap id="productResult" class="testdomain.Product" > >> groupBy="productId"> > >> <result property="productId" column="productid"/> > >> <result property="categoryId" column="category"/> > >> <result property="name" column="name"/> > >> <result property="description" column="descn"/> > >> <result property="itemList" resultMap="itemResult"/> > >> </resultMap> > >> > >> <resultMap id="itemResult" 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> > >> > >> <select id="getAllCategories" resultMap="categoryResult" > > >> select * > >> from category c, product p, item i, inventory v > >> where c.catid = p.category > >> and p.productid = i.productid > >> and i.itemid = v.itemid > >> </select> > >> > >> <select id="getFish" resultMap="categoryResult" > > >> select * > >> from category c, product p, item i, inventory v > >> where c.catid = p.category > >> and p.productid = i.productid > >> and i.itemid = v.itemid > >> and c.catid = 'FISH' > >> </select> > >> > >> > >> On 6/8/05, Ersin Er <[EMAIL PROTECTED]> wrote: > >> > >> > >>> Brandon Goodin wrote: > >>> > >>> > >>> > >>>> This will help you: > >>>> http://opensource.atlassian.com/confluence/oss/display/IBATIS/How+do+I+get+around+the+N+Plus+1+selects+problem%3F > >>>> > >>>> > >>>> > >>>> > >>> > >>> Infact, the document is the same as the Developer's Guide. What a pity, > >>> it did not help me. Anyway, I'm trying and learning myself. > >>> > >>> The groupBy attribute's value is a class property, not a table column, > >>> right? > >>> > >>> > >>> > >>>> On 6/6/05, Ersin Er <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> What is the porpose of "groupBy" attribute used in the SQL Mapper > >>>>> doc for > >>>>> "Complex Collection Properties" subject? It says "The important > >>>>> items here > >>>>> are the groupBy="quarter" attribute.." but it doesn't say why. > >>>>> I've tried > >>>>> my own example for 1:M relations and I did not the effect of groupBy > >>>>> attribute clearly. (After a few examples, a new sample doc will > >>>>> come.. :) > >>>>> ) > >>>>> > >>>>> Thanks. > >>>>> > >>>>> -- > >>>>> Ersin > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > >