[
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-cascade-setnull.diff
derby-6576-cascade-setnull.status
Attacking {^derby-6576-cascade-setnull.diff}, which adds logic to handle the
case of cascading delete and set null referential actions when the referenced
key is deferred. The run-time check is only done for deferrable referenced
keys, so old code paths should not be impacted modulo a simple boolean check or
two.
For both these cases, we remember all the keys that were deleted in the primary
table and after we check if there are still any duplicates left. If so, no
cascading action is taken.
Test cases added. An earlier version of this patch passed regressions, so
please review.
> 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)
