db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5120) Row from SYSDEPENDS gets deleted when a table has update triggers defined on it and an upate is made to the table
Date Thu, 14 Jul 2011 16:07:00 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mamta A. Satoor updated DERBY-5120:
-----------------------------------

    Attachment: DERBY5120_patch5_stat.txt
                DERBY5120_patch5_diff.txt

Attaching final patch which is ready for commit. The reason newly added upgrade test(from
patch 4) is failing with 10.5.1.1, 10.5.3.0, 10.6.1.0 and 10.6.2.1 releases is that those
releases have DERBY-4835 fix missing from them.

        During the upgrade time, the clearing of stored statements(including trigger action
spses) happened conditionally before DERBY-4835 was fixed. DERBY-4835 made changes so that
the stored statements get marked invalid unconditionally during the upgrade phase. But these
changes for DERBY-4835 did not make into 10.5.1.1, 10.5.3.0, 10.6.1.0 and 10.6.2.1. Because
of this missing fix, trigger action spses do not get marked invalid when the database is taken
after soft upgrade back to the original db release(if the original db release is one of the
releases mentioned above). The newly added upgrade test relies on trigger action spses getting
invalid during upgrade phase and getting recompiled when they are fired next time around thus
altering the number of rows in sysdepends. Because of this, I have disabled the upgrade test
for those 4 releases.

I will go ahead and commit this patch

> Row from SYSDEPENDS gets deleted when a table has update triggers defined on it and an
upate is made to the table
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5120
>                 URL: https://issues.apache.org/jira/browse/DERBY-5120
>             Project: Derby
>          Issue Type: Task
>          Components: SQL
>    Affects Versions: 10.2.2.0, 10.8.1.2
>            Reporter: Mamta A. Satoor
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY5120_patch1_diff.txt, DERBY5120_patch1_stat.txt, DERBY5120_patch2_diff.txt,
DERBY5120_patch2_stat.txt, DERBY5120_patch3_diff.txt, DERBY5120_patch3_stat.txt, DERBY5120_patch4_diff.txt,
DERBY5120_patch4_stat.txt, DERBY5120_patch5_diff.txt, DERBY5120_patch5_stat.txt
>
>
> I have an ij script below which shows that the number of rows in SYSDEPENDS go down by
1 for the following test case after an update is made to a table with update triggers defined
on it. Am not sure what kind of problems the missing dependnecy might cause.
> connect 'jdbc:derby:c:/dellater/db1;create=true';
> CREATE TABLE ATDC_13_TAB1(c11 int, c12 int);
> insert into ATDC_13_TAB1 values (1,11);
> create table ATDC_13_TAB2(c21 int, c22 int);
> insert into ATDC_13_TAB2 values (1,11);
> create table ATDC_13_TAB3(c31 int, c32 int);
> insert into ATDC_13_TAB3 values (1,11);
> create table ATDC_13_TAB1_backup(c11 int, c12 int);
> insert into ATDC_13_TAB1_backup values (1,11);
>                 create trigger ATDC_13_TAB1_trigger_1 after update 
>                 on ATDC_13_TAB1 for each row mode db2sql 
>                 INSERT INTO ATDC_13_TAB1_BACKUP(C11) 
>                 SELECT C21 from ATDC_13_TAB2;
>                  create trigger ATDC_13_TAB1_trigger_2 after update 
>                 on ATDC_13_TAB1 for each row mode db2sql 
>                 INSERT INTO ATDC_13_TAB1_BACKUP 
>                  SELECT C31, C32 from ATDC_13_TAB3;
> -- following shows 14 rows
> select * from sys.sysdepends;
> update ATDC_13_TAB1 set c12=11;
> -- following shows only 13 rows
> I tried this on 10.2 and 10.8 and saw the same behavior on both. It seems like the dependency
that gets dropped is between the stored prepared statement and a table. Have not spent enough
time to find out more details but I thought it is worth pointing out the behavior
> select * from sys.sysdepends;

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message