[
https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998673#comment-13998673
]
Dag H. Wanvik edited comment on DERBY-6576 at 5/15/14 11:15 AM:
----------------------------------------------------------------
Unfortunately, the previous patch wasn't complete enough. We need to keep
better track of how many rows are deleted/modified of each key when we are
doing deferred code path deletes since the actual deletes doesn't happen until
after all the checking. The new patch (#3), does this by using a disk based
hash table. Then after going through all the rows/key to be deleted/updated, we
compare the number of key duplicate instances with the number of deletes.
Unless at least one remains in the referenced table we have a violation of the
foreign key constraint.
Added extra tests, including a test that uses a compound fk/pk to check that
the index mapping happens correctly when we save the keys to the temporary hash
table. Regressions ran ok.
was (Author: dagw):
Unfortunately, the previous patch wasn't complete enough. We need to keep
better track of how many rows are deleted/modified of each key when we are
doing deferred code path deletes since the actual deletes doesn't happen until
after all the checking. The new patch (#3), does this by using a disk based
hash table. The after going through all the rows/key to be deleted/updated, we
compare the number of key duplicate instances with the number of deletes.
Unless at least one remains in the referenced table we have a violation of the
foreign key constraint.
Added extra tests, including a test that uses a compound fk/pk to check that
the index mapping happens correctly when we save the keys to the temporary hash
table. Regressions ran ok.
> A immediate Fk constraint blows up iff its referenced PK is deferred and we
> modify a duplicate key column
> ---------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6576
> URL: https://issues.apache.org/jira/browse/DERBY-6576
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Attachments: derby-6576-2.diff, derby-6576-3.diff,
> derby-6576-3.status, derby-6576.diff, derby-6576.status
>
>
> Similar to the issue in DERBY-6559, except here we modify the key in the
> referenced table. This leads Derby to check for any referencing FK and throw,
> even if there are other (formerly) duplicate rows that satisfy the FK
> constraint.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
