[
https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012592#comment-14012592
]
Dag H. Wanvik commented on DERBY-6576:
--------------------------------------
The latest patch isn't good enough for complicated cascade closures. I am
currently investigating the way Derby computes the
closure of rows to be deleted as a result of a set of rows which have foreign
keys. If the primary key referenced by one or more foreign keys involved has
duplicates, the current computation of the closure breaks down. The current
patch works only for simple one level cascade chains, and is not for commit.
Unless I can find a satisfactory implementation for this soon, I might consider
forbidding foreign keys with cascade action on deferrable primary keys, and
work on a complete solution for the next major release.
> 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-cascade-setnull.diff,
> derby-6576-cascade-setnull.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)
