db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-6576) A immediate Fk constraint blows up iff its referenced PK is deferred and we modify a duplicate key column
Date Fri, 16 May 2014 11:24:28 GMT

    [ 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)

Mime
View raw message