[ 
http://issues.apache.org/jira/browse/DERBY-551?page=comments#action_12419777 ] 

Daniel John Debrunner commented on DERBY-551:
---------------------------------------------

I think there are a couple of issues with the approach to checking for 
procedures that modify data in a before trigger.

1) The field modifiesSqlData is parser wide, not specific to a single routine. 
This may cause issues when the call statement is like:

        CALL MYPROC(MYFUNC(), MYOTHERFUNC(2));

      This may work, but may be making false assumptions about the ordering of 
evaluating nodes.

       Also I don't see the field being reset at any time.

2) There is an existing mechanism for checking which routines are allowed, I 
would have expected this code to use the same functionality.
After looking into it, I see that it is a runtime check, not a compile time 
check.

The existing runtime check is to support the fact that SQL statements executed 
in a Java method are not known when the routine is created (in SQL) since they 
are executed using dynamic JDBC. So if a routine is declared as READS SQL DATA 
then when it is executed by Derby its level of 'SQL allowed' is set in the 
statement context . Then any JDBC statements executed by the Java method are 
checked against the current level. This includes routines, so a procedure that 
is declared READS SQL DATA will throw an exception at runtime if its Java 
method attempts to prepare an INSERT SQL statement, or  a CALL statement that 
executes another  SQL  procedure that is declared MODIFIES SQL DATA.
See StatementContext.setSQLAllowed(short, boolean);

So we could use the existing mechanism, which means a before trigger with a 
CALL procedure that is declared MODIFIES SQL DATA statement would succeed but 
would fail at runtime when fired.


> Allow invoking java stored procedures from inside a trigger. Make CALL a 
> valid statement in the trigger body.
> -------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-551
>          URL: http://issues.apache.org/jira/browse/DERBY-551
>      Project: Derby
>         Type: New Feature

>   Components: SQL
>     Versions: 10.1.1.0
>  Environment: All platforms
>     Reporter: Satheesh Bandaram
>     Assignee: Deepa Remesh
>      Fix For: 10.2.0.0
>  Attachments: ProcedureInTrigger_Tests_v1.html, derby-551-draft1.diff, 
> derby-551-draft1.status
>
> Derby currently doesn't allow CALL statement to be used in a trigger body. It 
> would be great to allow java stored procedure invocation inside a trigger. 
> Since Derby doesn't have SQL procedure language, triggers can only execute a 
> single SQL statement. If we allow stored procedures in triggers, it would be 
> possible to write a trigger that involves more than just one SQL statement. 
> Functions are currently allowed, but they are read-only.
> I believe it is fairly easy to support this enhancement. Need good amount of 
> testing though.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to