[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500768
]
Reece Garrett commented on OPENJPA-235:
---------------------------------------
Markus,
That is great news! Thanks for running those test and getting back to me.
Dereferenced means that a persistence capable object was either nulled or
replaced. I need to capture this information because the dereference may cause
a delete. If that is the case, then by the time the code gets to
OperationOrderUpdateManager there is no way to calculated the dependency
between the delete and the update which caused it without knowing who
dereferenced who.
As a concrete example: A has a non-nullable reference to B and no one else
refers to B. You replace B with B2 thus dereferencing B. B is now orphaned and
will be deleted. You get three rows generated:
Row 1: insert B2
Row 2: update A to point to B2
Row 3: delete B
So, row 2 depends on row 1 and row 3 depends on row 2. But, without knowing
that the state manager for row 2 was responsible for dereferencing the state
manager for row 3 (thus causing the delete) there is no way to know that row 3
depends on row 2. Without having that dependency row 3 could be run before row
2 and would violate the foreign key constraint.
As for your second question, no, non-nullable foreign keys are not the only
reason for constraint
dependencies. Unique key constraints also cause dependencies. With unique keys
an insert can depend on an update or delete and an update can depend on another
update or delete. I mentioned earlier that I have a plan for dealing with this
but decided that it would be best complete my patch for foreign keys first and
then tackle uniques. I have a post on the mailing list where I get into a bit
more detail. The post was placed on May 22nd and is titled "SQL ordering and
unique constraints".
Hope that all made sense. If you have any more questions please ask away.
Gokhan,
I'm sorry but I have not had a chance to apply your patch and try my code with
it yet. I'll try my best to get to it but assuming your patch corrects the
problem I was running into I see no reason why it won't work. I'm being lazy by
not looking but have you posted your issue as a bug and posted the patch for
these guys to test?
-Reece
> 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, sqlreorder.patch, sqlReorder2.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.
