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

[Geoffrey De Smet (JIRA)]

Merge does a useless refresh of a non-cascaded OneToMany List before de-initializing that List (testcase PATCH)
---------------------------------------------------------------------------------------------------------------

                 Key: EJB-347
                 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-347
             Project: Hibernate Entity Manager
          Issue Type: Improvement
          Components: EntityManager
    Affects Versions: 3.3.2.GA
            Reporter: Geoffrey De Smet


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 :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira