openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gokhan Ergul (JIRA)" <j...@apache.org>
Subject [jira] Created: (OPENJPA-255) Inconsistent behavior during merge with cascade=none
Date Fri, 08 Jun 2007 22:39:26 GMT
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.


Mime
View raw message