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-2041) Trigger should register a dependency on tables and columns used in its body
Date Fri, 15 Nov 2013 14:11:25 GMT

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

Knut Anders Hatlen commented on DERBY-2041:
-------------------------------------------

The edge case mentioned above, where a foreign key causes DROP TABLE to think the trigger
references the table, seems to happen because DMLModStatementNode.createConstraintDependencies()
adds all referencing tables as dependencies. The comments indicate that these dependencies
are added in order to make statements recompile if the referencing tables change, and not
in order to restrict or cascade DROP operations. One possible way forward might be to make
this code skip adding those dependencies if the dependent is a TriggerDescriptor. The dependencies
are still added to the SPSDescriptor, so the trigger action should be able to detect that
it needs to be recompiled even if the TriggerDescriptor itself doesn't depend on the table.

> Trigger should register a dependency on tables and columns used in its body
> ---------------------------------------------------------------------------
>
>                 Key: DERBY-2041
>                 URL: https://issues.apache.org/jira/browse/DERBY-2041
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation, SQL
>    Affects Versions: 10.3.1.4
>            Reporter: Bryan Pendleton
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>              Labels: derby_triage10_11
>         Attachments: d2041-1a.diff, register-dependencies.diff
>
>
> A trigger registers a dependency in the Dependency Manager for those columns which cause
the firing of the trigger, but does not register a dependency on tables and columns which
are used in the body of the trigger. This means that the trigger may unexpectedly become invalid
due to a change to one of those tables and columns in its body, and the user may be surprised
that Derby did not warn them of this problem when the underlying table/column change was made.
> An example of this problem is as follows:
> create table t1 (c1 int);
> create table t2 (c2 int);
> create trigger tr1 after update of c1 on t1  for each row mode db2sql insert into t2
(c2) values (1);
> With this set of definitions, Derby will warn/prevent the user about changes to table
t1 and column c1, but will not warn the user about changes to table t2 and column c2. If the
user drops or renames t2 or c2, the trigger will then give an error the next time it fires.
> It seems like it would be an improvement for the trigger to record this dependency on
table t2 and column c2.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message