[
https://issues.apache.org/jira/browse/DERBY-6726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton updated DERBY-6726:
-----------------------------------
Attachment: getTableDescriptor.diff
Attached 'getTableDescriptor.diff' is an alternate patch proposal.
In some ways, this patch seems more precise and desirable, as it
fixes the problem closer to the symptom, that is, inside TriggerDescriptor
itself, which is the class that **ought** to encapsulate the knowledge of
the lazy-initialization of the 'td' member field. The other patch could be
critiqued because it allowed that knowledge to "leak out" into the
TriggerEventActivator class.
The new patch passes the reproduction script; I'll do more testing.
> 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, fixesRepro.diff,
> getTableDescriptor.diff
>
>
> 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)
