db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6383) Update trigger defined on one column fires on update of other columns
Date Thu, 31 Oct 2013 12:25:19 GMT

    [ 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)

Mime
View raw message