[ http://issues.apache.org/jira/browse/IBATIS-136?page=comments#action_12314421 ]
Sven Boden commented on IBATIS-136: ----------------------------------- I've been debugging the problem a bit, but I will require some guidance. The problem is in com.ibatis.sqlmap.engine.builder.xml.SqlMapParser method addResultMapNodelets(). The problem is that currently for "extends" only the column resultmappings are taken over, and not the <groupby> attribute. Several possible solutions: 1) The current behaviour is what is intentended with extends. But this seems to contradict the <groupby> documentation in "SQL Maps for Java" since "all properties" will be taken over. 2) The <groupby> should also be taken over when using extends. Some more open issues then: If the ResultMap that does the "extends" also has a <groupby> what to do then: 2a) Use the groupby of the original ResultMap, or possibly throwing an exception 2b) Take the groupby from the original ResultMap and add the groupby of the ResultMap that does the "extends" at the back. 2ba) Then maybe also make sure you can only do a <groupby> on the properties defined in the current ResultMap and not of those higher up in the "hiereachy" or not? Regards, Sven > Unexpected interaction between "groupBy" and "extends" resultmap attributes > --------------------------------------------------------------------------- > > Key: IBATIS-136 > URL: http://issues.apache.org/jira/browse/IBATIS-136 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.1.0 > Environment: MS Windows XP Professional, JDK 1.3 > Reporter: Geoff Chiang > Priority: Minor > > If a resultmap extends another by means of the "extends" attribute, any > grouping information in the "base" resultmap is not correctly reflected in > any created objects when using the extended resultmap. > Consider the following resultmaps: > <resultMap id="communicationSearchResult" class="communication" > groupBy="communicationID"> > <result property="communicationID" column="communication_id"/> > <result property="communicationDate" column="communication_date"/> > <result property="communicationType" column="communication_type_id" > typeHandler="communicationTypeTHC"/> > <result property="title" column="subject_1"/> > <result property="subject" column="subject_2"/> > <result property="customers" resultMap="Customer.customerResult"/> > </resultMap> > <resultMap id="communicationResult" class="communication" > extends="Communication.communicationSearchResult"> > <result property="details" column="contact_detail" jdbcType="CLOB"/> > </resultMap> > Note the grouping on the "customers" attribute in the base resultmap. > Execution of a query which uses the "communicationResult" result map will > result in the "customers" attribute having a null value, despite the fact > that the query clearly returns the correct data. > A workaround for this is to repeat the grouping information in the extended > resultmap, for example: > <resultMap id="communicationResult" class="communication" > extends="Communication.communicationSearchResult" groupBy="communicationID"> > <result property="details" column="contact_detail" jdbcType="CLOB"/> > <result property="customers" resultMap="Customer.customerResult"/> > </resultMap> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
