[
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
