You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Stuart Piltch (JIRA)" <ib...@incubator.apache.org> on 2006/02/17 03:06:27 UTC
[jira] Created: (IBATIS-260) Hash conflict with groupBy resultMaps
Hash conflict with groupBy resultMaps
-------------------------------------
Key: IBATIS-260
URL: http://issues.apache.org/jira/browse/IBATIS-260
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.7
Environment: iBatis 2.1.7
MacOS 10.4.4
MySQL 5.0.18
Reporter: Stuart Piltch
Priority: Minor
I've found another issue that's similar to the one reported (by me) and fixed (by Clinton) back in Jira iBatis-79
I have pretty much the same setup as last time, but the problem now is:
1) If there are nested groups, such as topic_category.name --> topic.name --> count(*)
2) If the same 2nd level name exists in more than one 1st level, such as the same topic.name existing in more than one topic_category
then only one 2nd level name (topic.name) is used as the hash. Only the last (or the first - haven't really checked that part) assignment is loaded. In my example, three separate topic categories have the same topic name and only one of the names gets assigned in the resultMap. The raw SQL query correctly shows counts in all three categories.
Changing the topic names in the db slightly makes the problem go away.
--
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
[jira] Commented: (IBATIS-260) Hash conflict with groupBy
resultMaps
Posted by "Sven Boden (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-260?page=comments#action_12366882 ]
Sven Boden commented on IBATIS-260:
-----------------------------------
Found the bug, but haven't found a solution to it yet.
The problem is as follows: if you take every groupBy as a level in a hierarchy. The problem is that there's a HashMap per level to store the keys in (to find out to which group an object maps to), but the key of such a group only takes into account the groupby attributes of the current level.
So if you have a table of category, topic, topic description with following data:
'Combat', 'Health', 'desc 1'
'Health', 'Health', 'desc 2'
'Test', 'Health', 'desc 3'
For category everything works out fine, they get split in 3 groups. For the second level grouping only the value for topic is taken into account so all 3 rows get assigned to one list and that list gets assigned to Combat in this case (because that one created the second level map first)
The trick would be to take into account the parent groupby values (of all previous levels), but this is not done yet and doesn't seem to be very easy to get at.
Regards,
Sven
> Hash conflict with groupBy resultMaps
> -------------------------------------
>
> Key: IBATIS-260
> URL: http://issues.apache.org/jira/browse/IBATIS-260
> Project: iBatis for Java
> Type: Bug
> Components: SQL Maps
> Versions: 2.1.7
> Environment: iBatis 2.1.7
> MacOS 10.4.4
> MySQL 5.0.18
> Reporter: Stuart Piltch
> Priority: Minor
>
> I've found another issue that's similar to the one reported (by me) and fixed (by Clinton) back in Jira iBatis-79
> I have pretty much the same setup as last time, but the problem now is:
> 1) If there are nested groups, such as topic_category.name --> topic.name --> count(*)
> 2) If the same 2nd level name exists in more than one 1st level, such as the same topic.name existing in more than one topic_category
> then only one 2nd level name (topic.name) is used as the hash. Only the last (or the first - haven't really checked that part) assignment is loaded. In my example, three separate topic categories have the same topic name and only one of the names gets assigned in the resultMap. The raw SQL query correctly shows counts in all three categories.
> Changing the topic names in the db slightly makes the problem go away.
--
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
[jira] Commented: (IBATIS-260) Hash conflict with groupBy
resultMaps
Posted by "Sven Boden (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-260?page=comments#action_12367080 ]
Sven Boden commented on IBATIS-260:
-----------------------------------
I attached the final version of the fix for IBATIS-260 to the JIRA if anyone would want to look over it. The fix has been verified by the original creator of the JIRA, by my, and I also have a JUnit testcase. I plan to check it in tomorrow evening.
Highlights:
- new property in RequestScope to track the nested keys for hierachical groupBys
- BasicResultMap's getUniqueKey now can take a prefix and appends a "separator"
> Hash conflict with groupBy resultMaps
> -------------------------------------
>
> Key: IBATIS-260
> URL: http://issues.apache.org/jira/browse/IBATIS-260
> Project: iBatis for Java
> Type: Bug
> Components: SQL Maps
> Versions: 2.1.7
> Environment: iBatis 2.1.7
> MacOS 10.4.4
> MySQL 5.0.18
> Reporter: Stuart Piltch
> Priority: Minor
> Attachments: ibatis-260-checkin.zip
>
> I've found another issue that's similar to the one reported (by me) and fixed (by Clinton) back in Jira iBatis-79
> I have pretty much the same setup as last time, but the problem now is:
> 1) If there are nested groups, such as topic_category.name --> topic.name --> count(*)
> 2) If the same 2nd level name exists in more than one 1st level, such as the same topic.name existing in more than one topic_category
> then only one 2nd level name (topic.name) is used as the hash. Only the last (or the first - haven't really checked that part) assignment is loaded. In my example, three separate topic categories have the same topic name and only one of the names gets assigned in the resultMap. The raw SQL query correctly shows counts in all three categories.
> Changing the topic names in the db slightly makes the problem go away.
--
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
[jira] Closed: (IBATIS-260) Hash conflict with groupBy resultMaps
Posted by "Sven Boden (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-260?page=all ]
Sven Boden closed IBATIS-260:
-----------------------------
Fix Version: 2.2.0
Resolution: Fixed
Assign To: Sven Boden
Fix for IBATIS-260 as described in previous JIRA entry is checked in.
> Hash conflict with groupBy resultMaps
> -------------------------------------
>
> Key: IBATIS-260
> URL: http://issues.apache.org/jira/browse/IBATIS-260
> Project: iBatis for Java
> Type: Bug
> Components: SQL Maps
> Versions: 2.1.7
> Environment: iBatis 2.1.7
> MacOS 10.4.4
> MySQL 5.0.18
> Reporter: Stuart Piltch
> Assignee: Sven Boden
> Priority: Minor
> Fix For: 2.2.0
> Attachments: ibatis-260-checkin.zip
>
> I've found another issue that's similar to the one reported (by me) and fixed (by Clinton) back in Jira iBatis-79
> I have pretty much the same setup as last time, but the problem now is:
> 1) If there are nested groups, such as topic_category.name --> topic.name --> count(*)
> 2) If the same 2nd level name exists in more than one 1st level, such as the same topic.name existing in more than one topic_category
> then only one 2nd level name (topic.name) is used as the hash. Only the last (or the first - haven't really checked that part) assignment is loaded. In my example, three separate topic categories have the same topic name and only one of the names gets assigned in the resultMap. The raw SQL query correctly shows counts in all three categories.
> Changing the topic names in the db slightly makes the problem go away.
--
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
[jira] Commented: (IBATIS-260) Hash conflict with groupBy
resultMaps
Posted by "Sven Boden (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-260?page=comments#action_12366929 ]
Sven Boden commented on IBATIS-260:
-----------------------------------
Fix that solves IBATIS-260 attached to JIRA, not checked in to SVN yet.
After someone else verifies the fix and my local unit test case for it is cleaned up, I will check it in.
> Hash conflict with groupBy resultMaps
> -------------------------------------
>
> Key: IBATIS-260
> URL: http://issues.apache.org/jira/browse/IBATIS-260
> Project: iBatis for Java
> Type: Bug
> Components: SQL Maps
> Versions: 2.1.7
> Environment: iBatis 2.1.7
> MacOS 10.4.4
> MySQL 5.0.18
> Reporter: Stuart Piltch
> Priority: Minor
> Attachments: ibatis.zip
>
> I've found another issue that's similar to the one reported (by me) and fixed (by Clinton) back in Jira iBatis-79
> I have pretty much the same setup as last time, but the problem now is:
> 1) If there are nested groups, such as topic_category.name --> topic.name --> count(*)
> 2) If the same 2nd level name exists in more than one 1st level, such as the same topic.name existing in more than one topic_category
> then only one 2nd level name (topic.name) is used as the hash. Only the last (or the first - haven't really checked that part) assignment is loaded. In my example, three separate topic categories have the same topic name and only one of the names gets assigned in the resultMap. The raw SQL query correctly shows counts in all three categories.
> Changing the topic names in the db slightly makes the problem go away.
--
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