[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3217) Merge does a useless refresh of a non-cascaded OneToMany List before de-initializing that List (testcase PATCH)

Merge does a useless refresh of a non-cascaded OneToMany List before de-initializing that List (testcase PATCH) --------------------------------------------------------------------------------------------------------------- Key: HHH-3217 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3217 Project: Hibernate3 Issue Type: Improvement Affects Versions: 3.2.6 Reporter: Geoffrey De Smet Attachments: EJB-347.patch Testcase patch attached. When merging a detached Author which had it's songs fetched (but there is no cascading to those songs), hibernate first does a useless check if all those songs still exist (but doesn't check their optimistic lock), and then returns the Author with a not intialized songs list. That check is very inconsistent: - if a song has been updated, it works, except that it shows an n +1 query problem (wihen not using BatchSize) - if a song has been deleted, it crashes, even though the merge isn't cascaded. It doesn't give an OptmisticLockingException, but this exception: javax.persistence.EntityNotFoundException: Unable to find org.hibernate.ejb.test.cascade.Song with id 51 If this behaviour is mandated by the JPA spec, an annotation, much like @OptimisticLock(excluded = true), to turn off this unwanted behaviour, would be wonderfull :)