Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 31 Oct 2013 12:25:19 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12674782.1382358808226.549.1383222319109@arcas>
In-Reply-To: <JIRA.12674782.1382358808226@arcas>
References: <JIRA.12674782.1382358808226@arcas>
Subject: [jira] [Commented] (DERBY-6383) Update trigger defined on one
 column fires on update of other columns
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen commented on DERBY-6383:
-------------------------------------------

I think this failure means the test change made the create phase corrupt the SYSSTATEMENTS table when running the upgrade tests against 10.5.1.1, 10.5.3.0, 10.6.1.0 or 10.6.2.1. The corruption happens because of DERBY-4577. When the upgrade test tries to boot the corrupted database in soft upgrade mode, an assert added in DERBY-4577 detects the corruption and raises an error.

Since the corruption happens in old, already released versions of Derby, and it's too late to fix the bug in those versions now, I think we could just disable this test case if the old version suffers from DERBY-4577 (that is, older than 10.7.1.1).

Actually, I don't think this is the kind of bug fix where we usually add an upgrade test. The patch doesn't attempt to fix this problem for existing triggers on upgrade (I don't think it could, since the information about which columns the original CREATE TRIGGER statement specified is lost). The main difference between the upgrade test case and the TriggerTest test case seems to be that the upgrade test case verifies that CREATE TRIGGER doesn't work as expected on some specific old versions. Since the behaviour of the already released versions is never going to change, we don't need to spend time testing that behaviour. The testing of the behaviour of the new version looks more or less the same as what was added to TriggerTest, so maybe it would be good enough coverage if we simply skipped the upgrade test case. Then we'd avoid the problem of having to find a workaround for DERBY-4577 altogether.

> Update trigger defined on one column fires on update of other columns
> ---------------------------------------------------------------------
>
>                 Key: DERBY-6383
>                 URL: https://issues.apache.org/jira/browse/DERBY-6383
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.7.1.4, 10.8.1.2, 10.9.1.0, 10.10.1.1
>            Reporter: Knut Anders Hatlen
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY6383_patch1_diff.txt, DERBY6383_patch2_diff.txt, d6383.sql, derby_for_Embedded_40Changes10_7testTriggers.log, derby_for_Embedded_40Changes10_9testDisposableStatisticsExplicit.log, error-stacktrace_for_Embedded_40Changes10_7testTriggers.out, error-stacktrace_for_Embedded_40Changes10_9testDisposableStatisticsExplicit.out, runall.out
>
>
> I see this problem on 10.8 and higher. To reproduce, create a database with a trigger like this:
> connect 'jdbc:derby:trigdb;create=true';
> create table t1(x int, y int);
> create table t2(x int, y int);
> create trigger tr after update of x on t1 referencing old table as old insert into t2 select * from old;
> Then run dblook on the database, and you'll see the following output:
> -- ----------------------------------------------
> -- DDL Statements for triggers
> -- ----------------------------------------------
> CREATE TRIGGER "APP"."TR" AFTER UPDATE OF "X", "Y" ON "APP"."T1" REFERENCING OLD_TABLE AS OLD FOR EACH STATEMENT insert into t2 select * from old;
> Notice that the DDL creates an update trigger for columns X and Y, whereas the original trigger was defined on column X only.
> I see the expected DDL on 10.7.1.1.


--
This message was sent by Atlassian JIRA
(v6.1#6144)