[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503698
]
Markus Fuchs commented on OPENJPA-235:
--------------------------------------
Hi all,
I propose the following steps to extend dependency management based on
the current implementation in ConstraintUpdateManager:
The current dependency calculation is based on a Depth First Search
(DFS) algorithm on the dependency graph defined by foreign key
constraints for inserts and deletes. Unique key constraints are
currently not handled.
1) Circles are identified by "BACK" edges found by the DFS and are
broken right there by nullifying the foreign key corresponding to
the "BACK" edge. This doesn't work, if this foreign key is not
nullable. Instead, I propose to identify the edges that contribute
to the circle in the NodeInfo corresponding to each graph node. If
we have the info about about the edges on the circle, we can walk
the circle and break it at the first *nullable* foreign key
found. Note, that there can't be a circle consisting of only
non-nullable foreign keys!
2) In a second phase, incorporate dependencies based on unique keys
into the graph construction. That means that instead of possibly
getting two independent graphs, one for inserts and one for
deletes, we'd always have just one graph including inserts,
updates, and deletes. The flush algorithm described in 1) would
stay the same, just the dependency graph would have additional
edges.
3) Independent rows (rows that weren't included in the dependency
graph) are currently flushed in random order. This might cause
deadlocks in the database. As an additional feature, we might want
to flush these rows in the order they were modified in the
transaction.
Does this make sense? What do you think? Did I miss anything?
Thanks,
-- markus.
> 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
> Assignee: Patrick Linskey
> Fix For: 0.9.8
>
> Attachments: merge-detached.patch,
> merge-multigen-collection-testcase.zip, openjpa-235-test.jar,
> openjpa-235-test1.jar, openjpa-235-test2.zip, sqlreorder.patch,
> sqlReorder2.patch, sqlReorderTests.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.
