db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2618) EmbedClob.setAsciiStream does not handle non-ascii characters correctly
Date Mon, 14 May 2007 21:42:16 GMT

    [ 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.


Mime
View raw message