openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe Alexis" <>
Subject Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading bidirectional collections during merge/attach
Date Thu, 17 May 2007 09:35:23 GMT
On 5/15/07, Gokhan Ergul <> 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
> (, which looks rather
> promising on that testcase as well.

Yes. Provided one follows Reece's example and annotates the field 'parent'
in and
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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message