openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gokhan Ergul <gokhan.er...@telenity.com>
Subject Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading bidirectional collections during merge/attach
Date Wed, 23 May 2007 00:46:26 GMT
Philippe Alexis wrote:
> ... snip
>>
>> > On MySQL, updateDetached works fine with the modification:
>> > @ManyToOne(cascade=CascadeType.ALL)
>> I'm assuming you're running without the patch I've included in the
>> testcase? With the patch it should work without messing around with
>> @ManyToOne.
>> >
>
>
> The thing with the patch is.. Is it a fix or a work-around that could now
> potentially be allowing cases
> that the initial implementation was meant to prevent?
> It looks like the exception is being thrown because B is not detached,
> indeed, it is new.
> Yet, there is a cached version of it.
>

The way I see it, the intent of  "Encountered new object B@..." 
exception is to catch freeriders, iow, to prevent attaching new objects 
where there's no defined cascade-merge relation from (the set of) 
currently attached object(s). The patch aims to fix cases where that 
"new object" has already been attached in active transaction context. In 
that particular test case, B is attached since it's been cascaded from A 
to B, and the fact that there's no cascade from C to B is irrelevant. 
Since it's just a 3-line patch, I'll go ahead and post it here:

Index: 
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/AttachStrategy.java
===================================================================
--- 
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/AttachStrategy.java  
(revision 509698)
+++ 
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/AttachStrategy.java  
(working copy)
@@ -270,6 +270,9 @@
             if (oid != null)
                 return manager.getBroker().find(oid, false, null);
         }
+        Object attachedCopy = manager.getAttachedCopy (toAttach);
+        if (null != attachedCopy)
+            return attachedCopy;
         throw new UserException(_loc.get("cant-cascade-attach",
             Exceptions.toString(toAttach), vmd,
             Exceptions.toString(sm.getManagedInstance()))).


So, I don't think it breaks an intentional check, but obviously I can't 
claim I'm seeing the whole picture --hence the need for review.

> The question is.. Why does OpenJPA expect, even force, the users to 
> allocate
> for cascading from child
> to parent regardless of whether they mean to or not?
>

I don't think that's the intention, but it's just a glitch.


Gokhan.




Mime
View raw message