db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api
Date Thu, 27 Jul 2006 12:55:15 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12423829 ] 
Knut Anders Hatlen commented on DERBY-1417:

Hi Kristian,

I have had a look at your patch, and I have a couple of comments and

  1) I believe using Lob.materializeStream() to get the length of a
     Clob is not correct. sqlLength_ is set to the number of bytes
     (UTF-8 encoded), not the number characters. I wrote a small test
     that called ResultSet.updateClob(int,Reader) and getClob() to get
     it back, and Clob.length() returned more than the number of
     characters when there were one or more non-ascii characters.

  2) EncodedInputStream uses "UTF8" and "UnicodeBigUnmarked" as
     encodings. These names are not necessarily understood by all
     JVMs. However, "UTF-8" and "UTF-16BE" (for which UTF8 and
     UnicodeBigUnmarked are aliases) must be supported by all JVMs, so
     it is probably better to use those names.

  3) Clob's constructor checks whether the supplied encoding is
     UnicodeBigUnmarked, but I didn't find that it was called with
     this encoding anywhere in the code. Could that part be removed?

  4) Clob's constructor checks whether the supplied encoding is
     US-ASCII, UTF-8 or UnicodeBigUnmarked, but if it's neither of
     those, no error is signalled. Wouldn't it be appropriate to throw
     some kind of SQLException? If so, SQLState.UNSUPPORTED_ENCODING
     sounds like a good choice.

  5) In ByteArrayCombinerStream, I think it would be good to convert
     the comments which describe the instance variables to
     javadoc. Also, the method description seems to be missing from
     the constructor and read(byte[],int,int).

  6) ByteArrayCombinerStreamTest is a subclass of BaseJDBCTestCase,
     but it's not a JDBC test. Shouldn't it have been a direct
     subclass of BaseTestCase?

  7) (minor) I have noticed in the svn log that there is an ongoing
     clean-up of the JUnit tests. Among other things, setUp and
     tearDown methods have been made protected instead of
     public. Maybe setUp and tearDown in ByteArrayCombinerStreamTest
     should be made protected too?

  8) (very minor) The condition in the while clause in
     ByteArrayCombinerStream.read(byte[],int,int) tests that (read !=
     length). I feel the code would be easier to read if the test was
     (read < length) since that would tell the reader that the read
     variable is increasing in the loop. Also, it wouldn't go into an
     infinite loop if there's an off-by-one error.


> Add new, lengthless overloads to the streaming api
> --------------------------------------------------
>                 Key: DERBY-1417
>                 URL: http://issues.apache.org/jira/browse/DERBY-1417
>             Project: Derby
>          Issue Type: New Feature
>          Components: JDBC
>    Affects Versions:
>            Reporter: Rick Hillegas
>         Assigned To: Kristian Waagan
>             Fix For:
>         Attachments: derby-1417-01-castsInTests.diff, derby-1417-1a-notImplemented.diff,
derby-1417-1a-notImplemented.stat, derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff,
derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, derby-1417-3b-embimpl-and-tests.stat,
derby-1417-4a-disable-psTestsDnc.diff, derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat,
derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, derby-1417-6b-clientimpl.diff,
> The JDBC4 Expert Group has approved a new set of overloads for the streaming methods.
These overloads do not take a length argument. Here are the new overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, java.io.InputStream
> CallableStatement.setBinaryStream(java.lang.String parameterName, java.io.InputStream
> CallableStatement.setCharacterStream(java.lang.String parameterName, java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, java.io.Reader
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, java.io.InputStream x, int
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when this methods
turn up in a published Mustang build.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message