[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4754: - Component/s: JDBC Urgency: Normal Labels: derby_triage10_8 (was: ) > 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: JDBC, SQL >Affects Versions: 10.6.1.0 >Reporter: Rick Hillegas > Labels: derby_triage10_8 > 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. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Comment: was deleted (was: Attaching derby-4066-02-ac-outputLOBs.diff. This patch allows LOB-valued OUT/INOUT arguments to Derby routines. Regression tests passed cleanly for me. As follow-on work, we will want to verify that large LOBs behave correctly. Hopefully, the work on DERBY-4544 will be applicable to DERBY-4754 and help improve the performance of LOB arguments. Touches the following files: -- M java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java Allow LOB types as OUT and INOUT arguments in routine declarations. -- M java/engine/org/apache/derby/impl/jdbc/EmbedCallableStatement.java Retrieve LOB values from OUT and INOUT parameters of CallableStatements. -- M java/client/org/apache/derby/client/net/NetCursor.java M java/drda/org/apache/derby/impl/drda/EXTDTAInputStream.java M java/drda/org/apache/derby/impl/drda/DRDAResultSet.java M java/drda/org/apache/derby/impl/drda/DRDAConnThread.java Transport LOB-valued OUT/INOUT parameters across the network. -- M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMappingTest.java Verify small LOB-valued OUT/INOUT arguments. ) > 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.
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Attachment: derby-4066-02-ac-outputLOBs.diff Attaching derby-4066-02-ac-outputLOBs.diff. This patch allows LOB-valued OUT/INOUT arguments to Derby routines. Regression tests passed cleanly for me. As follow-on work, we will want to verify that large LOBs behave correctly. Hopefully, the work on DERBY-4544 will be applicable to DERBY-4754 and help improve the performance of LOB arguments. Touches the following files: -- M java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java Allow LOB types as OUT and INOUT arguments in routine declarations. -- M java/engine/org/apache/derby/impl/jdbc/EmbedCallableStatement.java Retrieve LOB values from OUT and INOUT parameters of CallableStatements. -- M java/client/org/apache/derby/client/net/NetCursor.java M java/drda/org/apache/derby/impl/drda/EXTDTAInputStream.java M java/drda/org/apache/derby/impl/drda/DRDAResultSet.java M java/drda/org/apache/derby/impl/drda/DRDAConnThread.java Transport LOB-valued OUT/INOUT parameters across the network. -- M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMappingTest.java Verify small LOB-valued OUT/INOUT arguments. > 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.
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Issue & fix info: (was: [Patch Available]) > 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-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.
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Attachment: derby-4754-01-ab-harmonyLOBs.diff Attaching a second rev of the patch, derby-4754-01-ab-harmonyLOBs. This cleans up the previous rev, using Derby error messages instead of Harmony message ids. The replacement error messages are largely borrowed from EmbedBlob and EmbedClob. > 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-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.
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Issue & fix info: [Patch Available] > 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-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.
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Attachment: derby-4754-01-aa-harmonyLOBs.diff Attaching derby-4754-01-aa-harmonyLOBs.diff. This patch needs to be cleaned up a bit and I need to see what breaks when I run the regression tests. This patch adds the Harmony SerialBlob and SerialClob implementations to Derby. These are used as fallback implementations of Blob and Clob to be returned by SQLBlob.getObject() and SQLClob.getObject() when those data values do not wrap LOBs. Touches the following files: - M NOTICE Thanks Harmony for its code. - A java/engine/org/apache/derby/iapi/types/HarmonySerialBlob.java A java/engine/org/apache/derby/iapi/types/HarmonySerialClob.java The cloned Harmony code. - M java/engine/org/apache/derby/iapi/types/SQLChar.java M java/engine/org/apache/derby/iapi/types/SQLClob.java Fixes SQLClob.getObject() so that it always returns a java.sql.Clob. - M java/engine/org/apache/derby/iapi/types/SQLBlob.java M java/engine/org/apache/derby/iapi/types/SQLBinary.java Fixes SQLBlob.getObject() so that it always returns a java.sql.Blob. > 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-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.
[jira] Updated: (DERBY-4754) SQLClob.getObject() should always return a java.sql.Clob
[ https://issues.apache.org/jira/browse/DERBY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4754: - Affects Version/s: 10.6.1.0 Component/s: SQL > 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 > > 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.
