[ 
http://issues.apache.org/jira/browse/DERBY-551?page=comments#action_12421196 ] 
            
Daniel John Debrunner commented on DERBY-551:
---------------------------------------------

The changes using the relability mechansim seem fine, though the constant 
PROCEDURE_CALL_ILLEGAL seems worng. I would read that to mean all procedure 
calls are illegal, which is not the case. Clear naming of fields, methods etc. 
really helps people understand the code and reduce bugs due to misunderstanding.

I'm a little confused by the changes to 
InternalTriggerExecutionContext.validateStatement for the before trigger and 
DML section.
The patch reverts the code to its old state, what is the purpose of this 
changes and the resulting check left? Also the comment
that you just made in the previous patch was useful, but you have replaced it 
with a comment with less value. It seems to me
knowning that INSERT/UPDATE/DELETE statements are blocked by the parser is 
still useful information to have in this method.

-               // No INSERT/UPDATE/DELETE for a before trigger. Parser does 
not allow 
-               // these DML statements in a trigger's action statement in a 
before 
-               // trigger. Currently, parser does not disallow creation of 
before 
-               // triggers calling procedures that modify SQL data. This 
runtime check
-               // is needed to not allow execution of these DML statements by 
procedures
-               // within a before trigger context. 
+               /*
+               ** No INSERT/UPDATE/DELETE on trigger table
+               ** for a before trigger.
+               */
                else if (triggerd.isBeforeTrigger() && 
                                constantAction instanceof 
WriteCursorConstantAction)
                {
-                       throw 
StandardException.newException(SQLState.LANG_NO_DML_IN_TRIGGER, 
triggerd.getName(), targetTableName);
+                       if (constantAction.modifiesTableId(targetTableId))
+                       {
+                               throw 
StandardException.newException(SQLState.LANG_NO_DML_IN_TRIGGER, 
triggerd.getName(), targetTableName);
+                       }

> 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
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.1.1.0
>         Environment: All platforms
>            Reporter: Satheesh Bandaram
>         Assigned To: Deepa Remesh
>             Fix For: 10.2.0.0
>
>         Attachments: derby-551-draft1.diff, derby-551-draft1.status, 
> derby-551-draft2.status, derby-551-draft3.diff, derby-551-draft3.status, 
> derby-551-patch1-v1.diff, derby-551-patch1-v1.status, 
> derby-551-patch2-v1.diff, derby-551-patch3-v1.diff, 
> derby-551-patch3-v1.status, derby-551draft2.diff, 
> ProcedureInTrigger_Tests_v1.html
>
>
> 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