[jira] [Updated] (DERBY-6576) A immediate Fk constraint blows up iff its referenced PK is deferred and we modify a duplicate key column

["Dag H. Wanvik (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-6576:
---------------------------------

    Attachment: derby-6576.status
                derby-6576.diff

Uploading a patch for this, with the needed logic, plus test cases. During the work, I discovered that the code path for deferred delete (delete was addressed in DERBY-6559) was still broken, so this patch fixes that hole, too.

Running regressions.

> 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.diff
>
>
> 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)