On 5/15/07, Gokhan Ergul <[EMAIL PROTECTED]> wrote:
rejects the patch, my plan is to sleep on it ;). I hope to get back to the issue when I have some time on my hands and possibly test Reece's SQL reordering patch (https://issues.apache.org/jira/browse/OPENJPA-235), which looks rather promising on that testcase as well.
Yes. Provided one follows Reece's example and annotates the field 'parent' in B.java and C.java with @ForeignKey The problem for updateDetached persists despite Reece's changes though.
For updateDetached (EntityManager em), I was able to get it to 'work' by > allowing cascading from C to B on the @ManyToOne That's something I'd avoid tbh, though it may fix the problem, it doesn't really make sense to cascade from dependent objects to container objects unless you have a good reason to do so.
I agree. I figured it might still serve as an indication of why the problem reported arises.
> 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 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? Is this something that can be improved, for which a fix would be welcome? J-Philippe.
