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

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?


Reply via email to