[
https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000483#comment-14000483
]
ASF subversion and git services commented on DERBY-6576:
--------------------------------------------------------
Commit 1595384 from [~dagw] in branch 'code/trunk'
[ https://svn.apache.org/r1595384 ]
DERBY-6576 A immediate Fk constraint blows up iff its referenced PK is deferred
and we modify a duplicate key column
Patch derby-6576-3. 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 patch does this by using a disk based hash table. Then after going
through all the rows/keys to be deleted/updated and adding them to the
hash table (one entry per unique key, with a counter), we compare the
number of key duplicate instances present with the number of (planned)
deletes. Unless at least one row would remain in the referenced table,
we have a violation of the foreign key constraint.
This method is used for both deletes in deferred row processing mode
and for updates, which always has this mode in the presence of foreign
key).
For deletes in direct delete code path, we simply check that at least
one row would remain when we do the delete.
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.
> 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)
