[
https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897900#action_12897900
]
Rick Hillegas commented on DERBY-4754:
--------------------------------------
After we improve the memory usage of the LOBs returned by SQLClob.getObject()
and SQLBlob.getObject() (see DERBY-4544), we should add a test case to
ParameterMappingTest to test LOB inout procedure args which are bigger than the
VM memory. Grep that file for makeBigClob and makeBigBlob to see where to plug
in this test. This should round off the work done on DERBY-4066.
> SQLClob.getObject() should always return a java.sql.Clob
> --------------------------------------------------------
>
> Key: DERBY-4754
> URL: https://issues.apache.org/jira/browse/DERBY-4754
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.6.1.0
> Reporter: Rick Hillegas
> Attachments: derby-4066-02-ac-outputLOBs.diff,
> derby-4754-01-aa-harmonyLOBs.diff, derby-4754-01-ab-harmonyLOBs.diff
>
>
> Depending on what SQLClob wraps (a string, a stream, a java.sql.Clob),
> SQLClob.getObject() sometimes returns a string and other times returns a
> java.sql.Clob. In at least one spot, the compiler expects that
> SQLClob.getObject() will always return a java.sql.Clob. See the final cast
> compiled by SQLToJavaValueNode.generateJavaValue(). I believe that the
> compiler is correct and SQLClob.getObject() should behave predictably.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
