[
http://issues.apache.org/jira/browse/DERBY-1718?page=comments#action_12436076 ]
A B commented on DERBY-1718:
----------------------------
> Any one know if the new format id will cause any errors when building the
> stored
> prepared statement descriptors list or when the trigger gets executed on 10.1
> ?
I don't really know all of the details on how SPS descriptors are "built" or
what is/is not written to disk for triggers, but I did run the following
scenario and everything appears to be working as expected:
- Create a 10.1 database
- Create tables t1 and t2 as shown in the description for this issue
- Disconnect/shutdown 10.1 database.
- Connect to 10.1 database with Derby 10.3 codeline, effectively doing a soft
upgrade.
- Create the trigger trigxml as shown in the description for this issue
- Disconnect/shutdown the database.
- Reconnect to the database using Derby 10.1 codeline (effectively "soft
downgrade")
- Execute an insert statement that fires the trigger. The insert statement
was successful,
as was the trigger statement action.
I admit I was a bit surprised to see this work at first. However, I then
looked at the SYS.SYSSTATEMENTs table and I noticed that when I first create
the trigger in 10.3, the "VALID" column is set to "true". But when I reconnect
with 10.1, the "VALID" column becomes "false". My understanding is that the
"false" value means that when the trigger is fired, it will first be
RE-compiled before getting executed. This would in turn mean that the new
format id for the 10.3 SqlXmlUtil class will never actually be read when
running in 10.1--instead, the trigger statement will be recompiled using 10.1
and thus we don't see any failures.
I don't know for sure what the mechanism is, but based on this behavior it
appears that any attempts to boot a database from a version that is different
from the most-recently-booted version causes all stored prepared statements to
be marked invalid and thus forces recompilation. It is this recompilation of
the trigger statements which allows the 10.3 trigxml to execute successfully
against a 10.1 database after a "soft downgrade" back to 10.1.
That's my understanding based on the tests I ran; if anyone knows otherwise or
would like to add more, please feel free...
And thanks Suresh for taking the time to review the patch. I wasn't even
thinking about upgrade issues when I did my review. Definitely true that more
eyes are better...
> creating an after insert trigger with trigger action involving xml datatype
> throws java.io.NottSerializableException
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1718
> URL: http://issues.apache.org/jira/browse/DERBY-1718
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0, 10.2.2.0
> Environment: Java Version: 1.4.2
> Java Vendor: IBM Corporation
> Reporter: Suresh Thalamati
> Assigned To: Yip Ng
> Fix For: 10.2.1.0
>
> Attachments: derby1718-trunk-diff01.txt, derby1718-trunk-diff02.txt,
> derby1718-trunk-stat01.txt, derby1718-trunk-stat02.txt, stk.txt
>
>
> creating an after insert trigger with trigger action involving xml datatype
> throws following error :
> ij> create trigger trigxml after insert on t1 for each statement mode db2sql
> insert into t2 values (1,
> xmlparse(document '<name> ram </name>' preserve whitespace));
> ERROR XSDAJ: Exception during write of a serializable or SQLData object
> ERROR XJ001: Java exception: 'org.apache.derby.iapi.types.SqlXmlUtil:
> java.io.No
> ton'.SerializableExcepti
> ij>
> repro:
> connect 'jdbc:derby:wombat;create=true';
> create table t1 (i int, x xml);
> create table t2 (i int, x xml);
> insert into t2 values (1,
> xmlparse(document '<name> suresh </name>' preserve whitespace));
> --- following trigger creation is failing ,.
> create trigger trigxml after insert on t1 for each statement mode db2sql
> insert into t2 values (1,
> xmlparse(document '<name> ram </name>' preserve whitespace));
--
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
