Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.
The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/TriggerImplementation
------------------------------------------------------------------------------
insert into y select x, y, z from new org.apache.derby.catalog.TriggerNewTransitionRows()
NEWTAB
}}}
+ === JDBC ResultSet implementations ===
+ For the row triggers the getNewRow and getOldRow return a JDBC !ResultSet that wraps a Derby
language !ResultSet.
+ This JDBC !ResultSet is obtained from the embedded driver using the !ConnectionContext.!getResultSet
method. This
+ code is in !InternalTriggerExecutionContext.!getOldRowSet and !getNewRowSet.
+
+ For the statement triggers the VTI JDBC !ResultSet is an instance of !TriggerOldTransitionRows
or !TriggerNewTransitionRows
+ which are JDBC 1.2 !ResultSets that wrap the JDBC !ResultSet obtained as for row triggers.
So the complete wrapping is:
+ {{{
+ TriggerOldTransitionRows > EmbedResultSet* > Language ResultSet
+ }}}
+
=== History ===
These classes (!TriggerOldTransitionRows, !TriggerNewTransitionRows, and !TriggerExecutionContext)
used to be part of the
public api for Cloudscape 5.x and earlier releases. These were removed as part of the public
api when Derby was
@@ -65, +76 @@
* Accessing multiple columns leads to multiple accesses getNewRow() and/or getOldRow()
methods.
* [http://issues.apache.org/jira/browse/DERBY-1258 DERBY-1258] Since accessing columns
is through JDBC for row triggers, columns with identical upper-cased names are not handled
correctly.
+ === Possible Changes ===
+ * Re-write triggers to not add the indirection through JDBC !ResultSet. Have old/new references
in action statements compile to specific !QueryTree nodes that access the data directly from
a Derby language !ResultSet.
+ * Continue with JDBC approach and add code as required to fix issues, e.g. a internal specific
!findColumn implementation that doesn't match JDBC but instead matches column on absolute
name. Might still require a wrapper JDBC object.
+