db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
Date Thu, 12 Aug 2010 19:18:16 GMT

    [ 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:
>            Reporter: Rick Hillegas
>         Attachments: derby-4066-02-ac-outputLOBs.diff, derby-4754-01-aa-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.

View raw message