Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 95FFE114B7 for ; Mon, 19 May 2014 22:39:38 +0000 (UTC) Received: (qmail 26705 invoked by uid 500); 19 May 2014 22:39:38 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 26617 invoked by uid 500); 19 May 2014 22:39:38 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 26500 invoked by uid 99); 19 May 2014 22:39:38 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2014 22:39:38 +0000 Date: Mon, 19 May 2014 22:39:38 +0000 (UTC) From: "Dag H. Wanvik (JIRA)" To: derby-dev@db.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (DERBY-6576) A immediate Fk constraint blows up iff its referenced PK is deferred and we modify a duplicate key column MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000570#comment-14000570 ] Dag H. Wanvik edited comment on DERBY-6576 at 5/19/14 10:38 PM: ---------------------------------------------------------------- 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. [Update: the interference for the SET NULL referential action too, so I'll make a combined patch for cater for the cascade and set null cases] was (Author: dagw): 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)