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] [Updated] (DERBY-2041) Trigger should register a dependency on tables and columns used in its body
Date Tue, 19 Nov 2013 11:59:21 GMT

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

Knut Anders Hatlen updated DERBY-2041:
--------------------------------------

    Attachment: d2041-1b.diff

I've given up on the edge case described above for now.

The suggested workaround did not work for a number of reasons: DMLModStatementNode.createConstraintDependencies()
doesn't get called with the TriggerDescriptor as a dependent. (These dependencies are collected
in the auxiliary provider list and copied to the TriggerDescriptor later. In fact, the TriggerDescriptor
doesn't even exist yet when the dependencies are collected.) So we cannot tell in that method
whether the dependencies are for a trigger or something else. And even if we could tell the
difference there, the dependency on the referencing table also gets added via other code paths
where it's equally difficult to tell whether it's a trigger dependency.

An alternative workaround that I explored, was to make TriggerDescriptor.prepareToInvalidate()
check if it was possible to parse and bind the trigger action and ignore the dependency if
it was still possible. That approach didn't work either, because the DROP operations check
the dependencies before they mark the object as dropped in the system tables, so recompilation
of the trigger action during invalidation will not detect that a dependency is about to be
dropped.

This edge case is somewhat similar to DERBY-1632, DERBY-1782 and DERBY-4681 where the dependency
manager is too strict. It might be possible to devise a fix for this particular case, but
it might also be that we need to build more flexibility into the dependency tracking to have
something that could be used for all these cases. In any case I think the edge case is small
enough that the current approach is a net improvement.

I'm uploading an updated patch (d2041-1b.diff) which cleans up some comments and adds more
test cases to TriggerTest.

All tests ran cleanly.

> 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, d2041-1b.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