Minor Description
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.
Attachments
Attachments
Issue Links
- relates to
-
OPENJPA-231 Incorrect handling of cascading bidirectional collections during merge/attach
-
- Closed
-