[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6718?page=c...
]
Reto Urfer commented on HHH-6718:
---------------------------------
After some inverstigation i think the problem is in the method isJoinedFetchEnabled of
class CascadeEntityJoinWalker.
If this method will be enhanced by calling also isJoinedFetchEnabledInMapping(config,
type) from the super class JoinWalker the queries will be created correctly.
New implementation of the method:
protected boolean isJoinedFetchEnabled(AssociationType type, FetchMode config,
CascadeStyle cascadeStyle) {
return ( type.isEntityType() || type.isCollectionType() ) &&
( cascadeStyle==null || cascadeStyle.doCascade(cascadeAction) ) &&
isJoinedFetchEnabledInMapping(config, type);
}
Non-cascaded lazy association loaded during merge
-------------------------------------------------
Key: HHH-6718
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6718
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.5, 3.6.6, 3.6.7
Environment: Derby & Oracle database
Reporter: Reto Urfer
Attachments: bug.zip
Scenario:
- Class A, B and C, no secondary cache
- OneToOne association between A and B, not cascaded, eagerly loaded
- OneToOne association between B and C, all cascaded, lazy loaded
If I retrieve A by id, only A and the associated B are loaded, which is completly what i
expected.
If I modify A when the instance is detached and later merge it again then A and the
associated B are loaded but together with B also C is loaded within a left outer join.
This results in very heavy performance impacts within our application.
I have added a zip file with a simple test case to reproduce the problem
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira