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] [Commented] (DERBY-6576) A immediate Fk constraint blows up iff its referenced PK is deferred and we modify a duplicate key column
Date Sat, 17 May 2014 00:52:14 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000570#comment-14000570
] 

Dag H. Wanvik commented on DERBY-6576:
--------------------------------------

There are some problems remaining for cascading referential action in the referred delete/row
update cases; the new mechanism interferes with correct operation for these, so I'll address
this in an upcoming patch.

> 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