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 17:48:16 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495695
] 

Daniel John Debrunner commented on DERBY-2618:
----------------------------------------------

> The default behavior for OutputStream.write(int), is to cast the int to char and then
call the abstract method write(char[],int,int). 

That's incorrect, the defined behaviour for OutputStream.write(int) is (jdk 6 javadoc):

   "The byte to be written is the eight low-order bits of the argument b. The 24 high-order
bits of b are ignored."

Thus when using setAsciiStream() there are no no-ASCII characters, since each write call only
handles values as bytes (0-255).

I agree Derby should not fail with a UTFDataFormatException when using setAsciiStream() but
it should not treat any characters as invalid,
all values passed into the write() calls are valid.

> 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
>         Attachments: 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