[
https://issues.apache.org/jira/browse/DERBY-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495790
]
Daniel John Debrunner commented on DERBY-2618:
----------------------------------------------
ClobStreamControl has issues over its handling of positions, getting confused
between byte position, character position, byte length and stream length.
If anyone knows the code could they supply some guidance?
ClobUtf8Writer maintains a field pos that is the position of the writer in
bytes. On its write call it calls ClobStreamControl.insertString() and
increments the position by the return from insertString(). This is where the
problem comes:
ClobUtf8Writer.write() is expecting ClobStreamControl.insertString() to
return the number of (UTF8 encoded) bytes written:
ClobStreamControl.insertString() javadoc indicates it returns the current
position in bytes
ClobStreamControl.insertString() actually returns the number of *characters*
written.
These three items are inconsistent.
There is another caller (EmbedClob.setString) of
ClobStreamControl.insertString() that does expect it to return the number of
characters written, but I think that can be obtained from its parameter 'len'.
Or is there a situation where less characters would be written?
> EmbedClob.setAsciiStream does not handle non-ascii characters correctly
> -----------------------------------------------------------------------
>
> Key: DERBY-2618
> URL: https://issues.apache.org/jira/browse/DERBY-2618
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.0.0
> Reporter: Kristian Waagan
> Assigned To: Daniel John Debrunner
> Attachments: derby2618_partial_v1.txt, derby2618_partial_v2.txt,
> Derby2618BugsInClobAsciiStream.java
>
>
> If non-ascii characters are written to the Writer returned by
> EmbedClob.setAsciiStream, Derby fails with a 'java.io.UTFDataFormatException'
> when the CLOB value is read back.
> I'm filing this bug with 'Major' priority, as the bug does not manifest
> itself when entering data, just when you try to get it back. Except from
> filtering the data yourself before entering it, I don't think there is any
> workaround.
> Sample stack trace from a modified test:
> 1)
> testClobAsciiWrite1ParamKRISTIWAA(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)java.sql.SQLException:
> Unable to set stream: 'java.io.UTFDataFormatException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:94)
> at org.apache.derby.impl.jdbc.Util.setStreamFailure(Util.java:246)
> at org.apache.derby.impl.jdbc.EmbedClob.length(EmbedClob.java:190)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.setClob(EmbedPreparedStatement.java:1441)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testClobAsciiWrite1ParamKRISTIWAA(LobStreamsTest.java:255)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88)
> Caused by: java.sql.SQLException: Unable to set stream:
> 'java.io.UTFDataFormatException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:135)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
> ... 22 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
