You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Gokhan Ergul (JIRA)" <ji...@apache.org> on 2007/06/09 00:39:26 UTC
[jira] Created: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
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.
[jira] Commented: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Xiaoqin Feng (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595752#action_12595752 ]
Xiaoqin Feng commented on OPENJPA-255:
--------------------------------------
openjpa-255 is already fixed by openjpa-419 on openjpa1.1.x branch. I think my recent added openjpa-jira-231-255-new.patch is not needed for this issue.
But fix for openjpa-231 on openjpa1.1.x and openjpa head will be different. I will attach patch to openjpa-231.
> 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.
[jira] Resolved: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey resolved OPENJPA-255.
-------------------------------------
Resolution: Fixed
> 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.
[jira] Updated: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Gokhan Ergul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gokhan Ergul updated OPENJPA-255:
---------------------------------
Attachment: openjpa-jira-255.patch
Testcase and fix attached.
> 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.
[jira] Updated: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-255:
------------------------------------
Fix Version/s: 1.1.0
> 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-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.
[jira] Commented: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Adish Abnave (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (OPENJPA-255) Inconsistent behavior during merge
with cascade=none
Posted by "Xiaoqin Feng (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiaoqin Feng updated OPENJPA-255:
---------------------------------
Attachment: openjpa-jira-231-255-new.patch
I added TestNoCascadeOneToOneMerge.java based on the test case provided in this bug.
The attached patch includes both tests and fixes for open-231 and open-255.
> 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.