[
https://issues.apache.org/jira/browse/DERBY-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-2350:
-----------------------
Attachment: d2350_v2.patch
Attaching d2350_v2.patch, which is Mike's original patch plus some changes in
iapi/types/XML.java to solve the error that he mentioned in his previous
comment.
The problem is actually in the "setValueFromResultSet()" method of XML.java.
That method is called from VTIResultSet and is used to "load" results from into
the target XML column. But that method does not set the 'xType" field, which
means it defaults to -1. Then later, when we try to normalize the XML value in
preparation for insertion into the XML column, we throw an error because an
xType of "-1" indicates that the XML value is not a well-formed DOCUMENT.
The easiest fix would be to add a single line to XML.setValueFromResult() that
sets "xType" to XML_DOC_ANY. However, I do not know if we can safely assume
that the string value in the received ResultSet is well-formed XML. My
inclination is to believe that we canNOT make such an assumption, though I
can't currently think of any examples to prove it. To be cautious we need
some admittedly ugly code to check the well-formedness of the string value in
question. (Since the result set object is java.sql.ResultSet , and since
"getObject()" won't work, we have to jump through some hoops to figure out if
the desired column is in fact an XML value).
The attached patch makes changes to set "xType" based on whether or not the
string value in question is well-formed XML. This is rather undesirable,
though, because this change in combination with Mike's change in
CreateTriggerNode means that we are now parsing each XML value *TWO* additional
times--once as part of the rewrite contributed by Mike, and again when we get
to setValueFromResultSet(). That seems like it could lead to pretty bad
performance very easily...
That said, though, I'm not sure what the alternatives are outside of the
trigger re-write mentioned by Dan and Mike in preceding comments. So I'm
posting this far-less-than-ideal solution in case people think it's worth
committing. I ran lang/TriggerTest.java and suites.XMLSuite on Windows using
ibm142 and saw no failures. I haven't run any other tests...
> Use of XML values in the action statement of a trigger throw exceptions.
> ------------------------------------------------------------------------
>
> Key: DERBY-2350
> URL: https://issues.apache.org/jira/browse/DERBY-2350
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Attachments: d2350_v2.patch, derby-2350.diff
>
>
> A trigger like, where V, V1 and V2 are columns of type XML will thrown an
> exception when fired.
> CREATE TRIGGER AIS AFTER INSERT ON T_MAIN
> REFERENCING NEW_TABLE AS N
> FOR EACH STATEMENT
> INSERT INTO T_ACTION_STATEMENT(A, V1, ID, V2)
> SELECT 'I', V, ID, V FROM N
> ERROR 38000: The exception 'java.sql.SQLException: An attempt was made to get
> a data value of type 'java.lang.Object' from a data value of type 'XML'.' was
> thrown while evaluating an expression.
> Most likely because triggers are implementing using VTIs and hence JDBC
> ResultSets and XML is not supported through JDBC yet.
> TriggerTest shows this issue, see the comment with the bug number to
> reproduce.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
