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-5120) Row from SYSDEPENDS gets deleted when a table has update triggers defined on it and an upate is made to the table
Date Mon, 04 Jul 2011 01:27:21 GMT

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

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

A typical CREATE TRIGGER goes through following steps as far as adding/deleting rows from
SYSDEPENDS tale
1)Any time a trigger is created, CreateTriggerConstantAction.executeConstantAction() sends
CREATE_TRIGGER invalidation to the trigger table as shown below(The list of objects getting
invalidated will include existing triggers defined on the trigger table).
		/*
		** Send an invalidate on the table from which
		** the triggering event emanates.  This it
		** to make sure that DML statements on this table
		** will be recompiled.  Do this before we create
		** our trigger spses lest we invalidate them just
		** after creating them.
		*/
		dm.invalidateFor(triggerTable, DependencyManager.CREATE_TRIGGER, lcc);

2)Next, CreateTriggerConstantAction.executeConstantAction() does the trigger action sps generation
		/*
		** Create the trigger action
		*/
		actionspsd = createSPS(lcc, ddg, dd, tc, tmpTriggerId, triggerSd,
						actionSPSId, spsCompSchemaId, actionText, false, triggerTable);

3) During trigger action sps generation, SPSDescriptor.compileStatement removes the existing
dependencies of trigger action sps in sysdepends as shown below
(for a trigger getting created the first time, there will be no SPS dependencies for the trigger
action SPS. The same code is called when a trigger is found invalid, in that case, there will
be existing trigger action SPS dependencies which will get dropped here) 	
		/*
		** Clear out all the dependencies that exist
		** before we recreate them so we don't grow
		** SYS.SYSDEPENDS forever.
		*/
		dm.clearDependencies(lcc, this, tc);
4)After clearing out existing dependencies, it adds the dependencies that it finds during
this compile SPSDescriptor.compileStatement()
			/*
			** Copy over all the dependencies to me
			*/
			dm.copyDependencies(preparedStatement, 	// from
					this, 	// to
					false,	// persistent only
					cm,
					tc);
5)After finishing with trigger action SPS generation, CreateTriggerConstantAction.executeConstantAction
adds the depdencies for the trigger descriptor on trigger action sps and on trigger table.
Additionally, it adds depedency on trigger action sps on trigger table(this is the dependency
which later gets dropped when a compile of trigger action sps had cleared existing trigger
action sps dependencies before regenerating the trigger action sps. The trigger action sps
regeneration
does not add the dependency between trigger action sps and trigger table
		dm.addDependency(triggerd, actionspsd, lcc.getContextManager());
		dm.addDependency(triggerd, triggerTable, lcc.getContextManager());
		dm.addDependency(actionspsd, triggerTable, lcc.getContextManager());

Following the steps above (to find what rows get added into SYSDEPENDS)for the first trigger
in the simpler example that I posted on 01/Jul/11
create trigger ATDC_13_TAB1_trigger_1 after update 
         on ATDC_13_TAB1 for each row mode db2sql 
          values(1); 
Step 4) will not find any dependencies for trigger action values(1); 
Step 5) will add three rows into SYSDEPENDS, namely 
a)dependency between triiger descriptor for ATDC_13_TAB1_trigger_1 and triiger action SPS

b)dependency between trigger descriptor for ATDC_13_TAB1_trigger_1 and triiger table ATDC_13_TAB1

3)dependency between triiger action SPS and triiger table ATDC_13_TAB1 

This is how, we end up with three rows for the first trigger ATDC_13_TAB1_trigger_1 

When the 2nd trigger(ATDC_13_TAB1_trigger_2) is created, it also results into adding 3 rows
into SYSDEPENDS but additionally in step 1), it invalidates the existing trigger ATDC_13_TAB1_trigger_1

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