openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-255) Inconsistent behavior during merge with cascade=none
Date Tue, 06 May 2008 18:40:56 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594674#action_12594674
] 

Patrick Linskey commented on OPENJPA-255:
-----------------------------------------

Hi,

The recent patch is somewhat corrupted; can you recreate and re-post?

> 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
>             Fix For: 1.1.0
>
>         Attachments: openjpa-jira-231-255-new.patch, openjpa-jira-255.patch
>
>
> 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