Inconsistent behavior during merge with cascade=none
----------------------------------------------------
Key: OPENJPA-255
URL: https://issues.apache.org/jira/browse/OPENJPA-255
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 0.9.7, 1.0.0
Reporter: Gokhan Ergul
Priority: Minor
Suppose you have 2 entities, A and B, with a unidirectional one-to-one relation
from A to B and cascade=none. Persist A, B1 and B2, where A.b == B1. Later
change A.b to B2 and merge, the operation may or may not succeed, depending on
the following conditions:
- If both A and B2 is detached, merge succeeds.
- If both A and B2 is attached, iow managed in the same entity manager, merge
succeeds.
- If A is detached and B2 is managed as above, merge fails with 'encountered
new object ...' exception.
(It doesn't matter if the objects are versioned or not.)
The latter case is a rather typical usecase involving a detached context, where
the server application unmarshalls a user-modified domain object, creates an
entity manager and further modifies that object before invoking merge (such as
setting A.b depending on values of other fields). There are two workarounds for
the issue: merge twice (merge/set server managed fields/merge), or explicitly
detach all such relation objects before calling merge, but obviously neither is
desirable.
Looking at the code, it all boils down to AttachStrategy.getReference(...)
method. This method is invoked whenever a relation with cascade=none is
encountered during merge operation (and only for that case). Yet this method
assumes that the object *must* be detached or it will throw the mentioned
exception --I don't see the logic behind that assumption.
Attached a testcase demonstrating that behaviour, and a possible fix for it
--based on the premise that the above assumption is not correct. If that's not
the case, I'd appreciate if someone can point me in the right direction as to
why cascade=none on any type of relation field requires a detached object.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
