]
Dirk commented on HHH-4135:
---------------------------
Glad to see that someone had finally time to look into this. However your definition took
me by surprise and I cannot see any advantage in it.
Before you reject this case you should have a look on the reference implementation.
EclipseLink behaves according to the spec and I believe the definition is very
"obvious". Rejecting means that you face a great performance impact when dealing
with large collections. Do you have a valid use case where this non-quite-spec behavior
makes sense?
Merging of one-to-many relations not JPA spec compliant for lazy
relations
--------------------------------------------------------------------------
Key: HHH-4135
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4135
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Environment: Hibernate 3.2.6, Hibernate EntityManager 3.4.0, Hibernate
Annotations 3.4.0, Oracle
Reporter: Dirk
Attachments: CascadeTest.zip
Topic has been posted to the Hibernate Forum. See
https://forum.hibernate.org/viewtopic.php?f=1&t=999398
Summary:
Suppose you have an object Master with one-to-many relation to Detail.
@Entity
public class Master implements Serializable {
@OneToMany(mappedBy = "master", cascade={CascadeType.MERGE,
CascadeType.PERSIST})
private List<Detail> details = new ArrayList<Detail>();
...
}
Master is loaded without fetching Detail (= lazy) and EntityManager is closed. Master is
now in detached state. Merging Master causes Hibernate EntityManager to eagerly load the
Detail collection although it is in lazy state. This is not JPA spec compliant.
JPA spec states: The persistence provider must not merge fields marked LAZY that have not
been fetched: it must ignore
such fields when merging. See 3.2.4.1 Merging Detached Entity State, p.51.
Tested also with the latest version of EclipseLink. EclipseLink behaves as expected.
Testcase attached (Netbeans 6.7).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: