[ http://issues.apache.org/jira/browse/IBATIS-352?page=comments#action_12461118 ] Paul Benedict commented on IBATIS-352: --------------------------------------
I believe I have the same problem as Andrew. However, it doesn't seem related to Sets, but any kind of collection that is in itself an Enum: I wrote a query which returns a user and its associated roles. The resultMap looks like this: <resultMap id="userMap" class="User" groupBy="id"> <result property="id" column="u_id" /> <result property="roles" column="ur_id" /> </resultMap> As you can see, I am grouping by "id" which means I should be collecting all my roles in property "roles" which is a List<Role>. I already have a type handler setup to translate the long into the enum/class, but it's not working. While I am using Java 5, this problem is not (I don't think) a Java 5 problem. I've seen many examples of using the @resultMap attribute on a collection to construct the objects to avoid N+1 selects. But what about just plain old Java types or enums? > Problems with Complex Properties + Sets & enums > ----------------------------------------------- > > Key: IBATIS-352 > URL: http://issues.apache.org/jira/browse/IBATIS-352 > Project: iBatis for Java > Issue Type: Bug > Components: SQL Maps > Affects Versions: 2.2.0 > Environment: JDK 1.5, IBATIS SQL Maps 2.2.0.638, Spring 2.0 > Reporter: Andrew Bethell > Attachments: domain.zip, join-resultmap with enum.txt, lazy-load with > set.txt, sqlmap.zip > > > There doesnt seem to be support for lazy-loading complex properties of type > 'java.util.Set', only List collections - (stack trace attached to this > issue). > I have to use Set collections at the moment, as when I upgraded from IBATIS > SQLMaps 2.17 to 2.22, the 'groupBy' attribute for resultmaps did not seem to > make data in (List) complex properties distinct by ID, where as in version > 2.17 this was the case. > Strangely though, when loading complex properties with joins+resultMaps, Set > properties work correctly - except when items in the Set contain enum types > (stack trace attached for this too). -- 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
