]
Emmanuel Bernard moved EJB-347 to HHH-3217:
-------------------------------------------
Affects Version/s: (was: 3.3.2.GA)
3.2.6
Component/s: (was: EntityManager)
Key: HHH-3217 (was: EJB-347)
Project: Hibernate3 (was: Hibernate Entity Manager)
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
:)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: