db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2350) Use of XML values in the action statement of a trigger throw exceptions.
Date Fri, 13 Jul 2007 22:21:04 GMT

     [ 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

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:
>            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.
>                 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.

View raw message