Thanks, Army. I don't seem to be able to access JIRA right now so I'm
responding on-list. This wouldn't happen to be a small-device platform,
would it? The handling of DECIMAL on the small device platform is
different. The test may need some special logic so that it calls the
correct method for the small device environment. Off the top of my head,
I don't understand how my recent changes would have destabilized this
test case. I recommend logging this as a new JIRA.
Thanks,
-Rick
A B (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578083#action_12578083 ]
A B commented on DERBY-3341:
----------------------------
I saw two failures when running suites.All with weme6.1 last night, both in
TableTestFunction with similar diffs. Ex:
noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException:
An attempt was made to get a data value of type 'java.lang.Object' from a data
value of type 'DECIMAL'.
at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source)
at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source)
at
o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935)
at
o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776)
at
o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762)
at
o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178)
at
o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921)
at
o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
Caused by: ERROR 22005: An attempt was made to get a data value of type
'java.lang.Object' from a data value of type 'DECIMAL'.
at o.a.d.iapi.error.StandardException.newException(Unknown Source)
at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source)
at o.a.d.iapi.types.DataType.getObject(Unknown Source)
at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source)
at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source)
at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source)
at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
The other failure was the "specialCollation()" fixture.
I'm guessing you're not running tests with weme6.1, but any chance you might be
able identify the cause? Or should I file a separate issue?
TABLE FUNCTION returning CHAR values does not return a correct value if the
Java ResultSet class returns a value less than the length of the defined CHAR.
----------------------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-3341
URL: https://issues.apache.org/jira/browse/DERBY-3341
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Daniel John Debrunner
Fix For: 10.4.0.0
Attachments: derby-3341-01-coerce.diff,
derby-3341-01-da-coerceWithTests.diff, derby-3341-02-aa-refGuide.diff,
derby_3341_test.txt, rrefcreatefunctionstatement.html
Defining a column in the returned type as CHAR(10) requires that the returned
value be of length 10 characters.
Defining a table function with a return type of:
returns TABLE column0 char( 10 ), column1 char( 10 ))
seems to just return whatever the Java ResultSet implementation handed it.
My guess this is true for all variable length types, no casting of the value
occurs when it is returned to the SQL domain.
Java single value functions and procedure out parameters do perform any
required casting to ensure the value is of the declared type.
