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] Commented: (DERBY-5079) DERBY-4984 caused a regression which will not allow users to drop a table if the table was involved in a trigger action rebind during ALTER TABLE DROP COLUMN
Date Tue, 01 Mar 2011 17:44:36 GMT

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

Mamta A. Satoor commented on DERBY-5079:
----------------------------------------

Following is the ij script showing the problem
java -Dij.exceptionTrace=true org.apache.derby.tools.ij
connect 'jdbc:derby:c:/dellater/db1;create=true';
CREATE TABLE ATDC_15_TAB1(a1 int, b1 int);
CREATE TABLE ATDC_15_TAB2(a2 int, b2 int);
insert into ATDC_15_TAB1 values(1,11);
insert into ATDC_15_TAB2 values(1,11);
create trigger atdc_15_trigger_1 after update 
                on atdc_15_tab1 REFERENCING NEW AS newt 
                for each row 
                update atdc_15_tab2 set b2 = newt.b1;
select * from sys.sysdepends;
alter table atdc_15_tab1 drop column a1 restrict;
select * from sys.sysdepends;
drop table ATDC_15_TAB1;
drop table ATDC_15_TAB2;

The drop of ATDC_15_TAB2 fails with following error
ERROR 42X94: Table '23ce809c-012e-7281-172d-0000003c7d78' does not exist.

The first select * from sys.sysdepends shows 5 rows which are correct and as follows
select * from sys.sysdepends;
DEPENDENTID                         |DEPENDENTFINDER|PROVIDERID             |PROVIDERFINDER
---------------------------------------------------------------------------------------------------------
560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&|846c00a0-012e-7281-172d-0000003c7d78|ColumnsInTable
560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&|8c9400a1-012e-7281-172d-0000003c7d78|Conglomerate
0ddd00a9-012e-7281-172d-0000003c7d78|Trigger        |560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&
0ddd00a9-012e-7281-172d-0000003c7d78|Trigger        |23ce809c-012e-7281-172d-0000003c7d78|Table
560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&|23ce809c-012e-7281-172d-0000003c7d78|Table
5 rows selected

But after the ALTER TABLE DROP COLUMN, it shows 3 extra rows, which is not correct
select * from sys.sysdepends;
560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&|846c00a0-012e-7281-172d-0000003c7d78|ColumnsInTable
560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&|8c9400a1-012e-7281-172d-0000003c7d78|Conglomerate
0ddd00a9-012e-7281-172d-0000003c7d78|Trigger        |560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&
0ddd00a9-012e-7281-172d-0000003c7d78|Trigger        |23ce809c-012e-7281-172d-0000003c7d78|Table
560740aa-012e-7281-172d-0000003c7d78|StoredPrepared&|23ce809c-012e-7281-172d-0000003c7d78|Table
23ce809c-012e-7281-172d-0000003c7d78|Table          |846c00a0-012e-7281-172d-0000003c7d78|Table
23ce809c-012e-7281-172d-0000003c7d78|Table          |846c00a0-012e-7281-172d-0000003c7d78|Table
23ce809c-012e-7281-172d-0000003c7d78|Table          |846c00a0-012e-7281-172d-0000003c7d78|Table
8 rows selected



> DERBY-4984 caused a regression which will not allow users to drop a table if the table
was involved in a trigger action rebind during ALTER TABLE DROP COLUMN
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5079
>                 URL: https://issues.apache.org/jira/browse/DERBY-5079
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.7.1.3, 10.8.0.0
>            Reporter: Mamta A. Satoor
>            Assignee: Mamta A. Satoor
>            Priority: Blocker
>
> The fix for DERBY-4984 has introduced a regression which adds rows into SYSDEPENDS which
are incorrect. The error I think was caused when before doing a rebind of trigger action,
I made the trigger table as the current dependent in the dependency system and hence all the
dependencies required by the trigger action got associated with that trigger table and hence
causing the errorneous behavior. I will work on this asap. The fix went into trunk and 10.7.
I will add a test case for this in the jira and will also add a test case in our junit test

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

        

Mime
View raw message