[
https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536760
]
Adish Abnave commented on OPENJPA-255:
--------------------------------------
How do i use the patched attached here? I am trying to build OpenJPA with the
patched code but getting maven Build error.Can some one send me or let me know
where i can get an openJpa jar with the patched code ?
> 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
> Attachments: 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.
