[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Fuchs updated OPENJPA-235:
---------------------------------
Attachment: openjpa-235-test1.jar
Hi Reece,
Thanks for trying my test case. I've been playing around with commit
dependencies, and this is, what I found:
1) One reason, why your previous patch didn't work is, as you already found
out, that the rows returned by RowManagerImpl.getInserts returns are not in
user order. This might be unexpected and should either be documented or changed
(I haven't found any usages of RowManagerImpl.getInserts in the current code,
so it might be possible to change that). An alternative would be to add a new
method RowManagerImpl.getOrderedInserts.
2) Another situation, that generally doesn't work (both w/ your patch and w/o),
is when relationships are nullified before the objects are deleted. Please see
my new test openjpa-235-test1. OpenJPA doesn't execute updates for deleted
objects. There will be a fk constraint violation if the updates are skipped and
the objects aren't modified according to the constraint dependencies inside the
user transaction. I couldn't find how to get "old" relationship value before
the update, which would be needed for the dependency calculation.
3) It seems, that join table entries are removed from the non-owning side.
IMHO, relationship updates should only be done from the owning side.
> SQL reordering to avoid non-nullable foreign key constraint violations
> ----------------------------------------------------------------------
>
> Key: OPENJPA-235
> URL: https://issues.apache.org/jira/browse/OPENJPA-235
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Reece Garrett
> Assigned To: Patrick Linskey
> Fix For: 0.9.8
>
> Attachments: openjpa-235-test.jar, openjpa-235-test1.jar,
> sqlreorder.patch
>
>
> OpenJPA does not do any SQL statement re-ordering in order to resolve foreign
> key constraints. Instead, objects are always inserted in the order in which
> the user persists the instances. When you persist in an order that would
> violate foreign key constraints, OpenJPA attempts to insert null and then
> update the foreign key value in a separate statement. If you use non-nullable
> constraints, though, you must persist your objects in the correct order.
> This improvement re-orders SQL statements as follows:
> 1. First, all insert statements execute. Inserts which have foreign keys with
> non-nullable constraints execute AFTER the foreign keys which they depend on
> have been inserted since no deferred update is possible.
> 2. Next, all update statements execute. No reordering is necessary.
> 3. Finally, all delete statements execute. Like inserts, deletes execute in
> an order which does not violate non-nullable foreign key constraints.
> If a circular foreign key reference is found during the re-ordering process
> then re-ordering halts and the remaining unordered statements are left as is.
> There is nothing that can be done about the circular reference (other than
> fixing the schema) and the resulting SQL statements will not succeed.
> The net effect is that users do not need to worry about the persistence order
> of their objects regardless of non-nullable foreign key constraints. The only
> class modified was
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. I have included a
> patch which includes my modifications to OperationOrderUpdateManager and test
> cases. The test cases I have provided fail on the current trunk but pass with
> my modifications. I have also verified that I did not break anything by using
> maven to run all test cases with my modifications in place.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
