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 Tue, 15 May 2007 00:09:23 GMT
Philippe Alexis wrote:
> Hi Gokhan,
>
> I'd been busy with work but kept this particular issue at the back of my
> mind for coming back to.
> How far did you get investigating it?
>
Not far I'm afraid --I'm still running with the patch I've posted on 
jira that fixes the detached case. Since the application we're currently 
developing is web-services based, all interactions take place in a 
detached context --hence I've no immediate need to address the attached 
case for the time being. Until a maintainer reviews and explicitly 
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.

> Firstly, I had no problem getting updateAttached (EntityManager em) to 
> run
> fine on both SQL Server and Postgresql,
> got the count of 4.
>
> 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.
>
> From the lack of response to this issue, I'm thinking this might be a 
> design
> decision the bigger picture of which is eluding me.
> Anyone would care to shed some light on this, why @ManyToOne(cascade=
> CascadeType.ALL) solves the problem reported?
>
> 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.
>
> But for updateAttached, the issue of apparently attempting to save 
> instances
> of C before those of B persists with and without
> the above change:
snip
> ===================================================
>     [java] Caused by: <0.9.7-incubating nonfatal general error>
> org.apache.openjpa.persistence.PersistenceException: Cannot add or 
> update a
> child row: a foreign key constraint fails (`test/test_c`, CONSTRAINT
> `FK_TEST_C_REFERENCE_TEST_B` FOREIGN KEY (`B_ID`) REFERENCES `test_b`
> (`B_ID`)) {prepstmnt 7832149 INSERT INTO TEST_C (c_id, B_ID) VALUES 
> (?, ?)
> [params=(int) 4, (int) 4]} [code=1452, state=23000]
>     [java] FailedObject: test.C@1236cd5
Yep, that's the one. The weird thing about that one is, I cannot 
reliably reproduce it: on some test runs sql order is correct, on others 
it's not. I can't really speculate on that before some involved 
debugging session.





Mime
View raw message