Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.1.1, 2.2.0
-
None
-
None
Description
Setting a FetchPlan on an entitymanager which loads a certain @OneToMany field that is marked as lazy and cascade all, can result in a different entityManager (created by the same factory) to eagerly fetch this field, even if the field is not in the fetchplan of this different entityManager.
I found two situations where this occurs (each step uses a different entityManager with a transaction):
1.
- em.merge a new entity (and cascaded related entity) with fetchgroup added
- find entity with no fetchgroup added
-> the lazy-fetched field is incorrectly loaded
2. - em.persist a new entity (and cascaded related entity) with NO fetchgroup added
- find entity with fetchgroup added
- find entity with NO fetchgroup added
-> the lazy-fetched field is incorrectly loaded
The weird thing is that persist and merge behave inconsistently - isn't that great, an inconsistency within an inconsistency? - because switching persist/merge results in the following situations that work as expected:
1.
- em.persist a new entity (and cascaded related entity) with fetchgroup added
- find entity with no fetchgroup added
-> the lazy-fetched field is a null reference (expected)
2. - em.merge a new entity (and cascaded related entity) with NO fetchgroup added
- find entity with fetchgroup added
- find entity with NO fetchgroup added
-> the lazy-fetched field is a null reference (expected)
Checking the trace and generated SQL confirms that the field that should not be fetched is in fact fetched.
I think this is a bug because this is both inefficient and is inconsistent because I wish my data access to behave predictably.
Note that turning on <property name="openjpa.DetachState" value="fetch-groups" /> in persistence.xml solves the issues but internally OpenJPA still performs the eager fetch.