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: [EMAIL PROTECTED]
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.
