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

Bernd Ruehlicke edited comment on DERBY-6726 at 9/30/16 2:07 PM:
-----------------------------------------------------------------

I have tracked down the problem,

First I was comparing sources changes between 7.1.1 and 8.1.2 to reduce amount 
of source to be checked and as I know it worked in 7.1.1. and failed in 8.1.2.  
GenericTriggerExecutor, RowTriggerExecutor. TriggerEventActivator, 
UpdateResultSet and GenericPreparedStatement where the same - so no problem 
should be in those.

The problem happens in :   iapi/sql/dictionary/TriggerDescriptor in the method 
getActionSPS.  (In 12.1.1. this is getSPS).

In 8.1.2 code was added to the method as part of DERBY-4874. When I comment out 
this extra code in the 8.1.2 code base - the Test works !  I do not currently 
understand what this extra code is doing, but it is for sure the culprit of the 
problem.

Now looking at the 12.1.1 code we have the same or similar code in 
TriggerDescriptor.getSPS(...). Again, commenting out the addition made for 
DERBY-4874 and just have it do the same as back in the 7.1.1 days - the code 
works also on 12.1.1

I will try to understand what the getSPS(..) is trying to do and why it falls 
over having a double set of AFTER UPDATE triggers, but maybe someone closer to 
the code can help with ideas as the problem is now pinned down to a few lines 
of source.



I will now go into the 12.1.1 code base and try to understand the logic here 


was (Author: bruehlicke):
I have tracked down the problem,

First I was comparing sources changes between 7.1.1 and 8.1.2 to reduce amount 
of source to be checked and as I know it worked in 7.1.1. and failed in 8.1.2.  
GenericTriggerExecutor, RowTriggerExecutor. TriggerEventActivator, 
UpdateResultSet and GenericPreparedStatement where the same - so no problem 
should be in those.

The problem happens in :   iapi/sql/dictionary/TriggerDescriptor in the method 
getActionSPS.  (In 12.1.1. this is getSPS).

In 8.1.2 code was added to the method as part of DERBY-4874. When I comment out 
this extra code in the 8.1.2 code base - the Test works !  I do not currently 
understand what this extra code is doing, but it is for sure the culprit of the 
problem.

Now looking at the 12.1.1 code we have the same or similar code in 
TriggerDescriptor.getSPS(...). Again, commenting out the addition made for 
DERBY-4874 and just have it do the same as back in the 7.1.1 days - the code 
works also on 12.1.1

I will try to understand what the getSPS(..) is trying to do and why it falls 
over having a double set of AFTER UPDATE triggers, but maybe someone closer to 
the code can help with ideas as the problem is now pinned down to a few lines 
of source.



I will now go into the 12.1.1 cod base and try to understand the logic here 

> NPE from trigger
> ----------------
>
>                 Key: DERBY-6726
>                 URL: https://issues.apache.org/jira/browse/DERBY-6726
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.10.1.1
>            Reporter: Tim Dudgeon
>         Attachments: TriggerTest.diff, derbytrig.zip
>
>
> Saw this strange exception when doing an insert to a table with a trigger
> {code}
> Tue Sep 02 13:39:09 BST 2014 Thread[SQLExecution,1,system] (XID = 62693), 
> (SESSIONID = 1), (DATABASE = 
> C:/Users/timbo/Documents/IJCProjects/mini-regs/Vanilla 
> Oracle/.config/derby-minireg-01-sep/db), (DRDAID = null), Failed Statement 
> is: UPDATE samples SET sample_code = 'S123456' WHERE sample_id = CAST 
> (org.apache.derby.iapi.db.Factory::getTriggerExecutionContext().getNewRow().getObject(1)
>  AS INTEGER)
> java.lang.NullPointerException
>     at 
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTriggerActionString(Unknown
>  Source)
>     at 
> org.apache.derby.iapi.sql.dictionary.TriggerDescriptor.getActionSPS(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.getAction(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(Unknown 
> Source)
>     at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
>     at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeSubStatement(Unknown
>  Source)
>     at 
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown 
> Source)
>     at 
> org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown 
> Source)
>     at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
>     at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source)
>     at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
>     at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
> Source)
>     at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
>     at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> {code}
> The trigger definition is this:
> {code}
> CREATE TRIGGER samples_code_trg
> AFTER INSERT ON samples
> REFERENCING NEW AS newrow FOR EACH ROW MODE DB2SQL
> UPDATE samples SET sample_code = 'S123456'
> WHERE samples.sample_id = newrow.sample_id;
> {code}
> As mentioned here: 
> http://mail-archives.apache.org/mod_mbox/db-derby-user/201408.mbox/%[email protected]%3E
> it could be that its caused by another AFTER UPDATE trigger that's on the 
> table.
> Unfortunately I rebuilt all the tables and triggers and not the problem 
> doesn't happen, so I can't provide a test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to