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 Fri, 28 Jul 2006 10:21:15 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12424055 ] 
Knut Anders Hatlen commented on DERBY-1417:

I did some investigation on the existing Clob implementation on the
client. It might be relevant to the work on this issue. Here's a
summary of my findings:

There are three methods which return the length of the Clob:

  - length() which is supposed to return the length in characters
  - getByteLength() which is supposed to return the length in bytes
    for whatever the underlying encoding is
  - getUTF8Length() which is supposed to return the length of the Clob
    if it is UTF-8 encoded

length() and getByteLength() always return the same value, but what
they return is not consistent.

getUTF8Length() only works if the Clob object was created with the
constructor that takes a string parameter.

If the Clob was created with the constructor that takes a Reader,
length() and getByteLength() return the length in characters. These
clobs are sent UTF-16BE encoded over DRDA, hence their length in bytes
is actually twice their length in characters. getUTF8Length() will
throw a NullPointerException (as will position() and getSubString()).

If the Clob was created with the InputStream constructor, the encoding
has to be specified explicitly. Three encodings are supported:
US-ASCII, UTF-8 and UnicodeBigUnmarked (aka UTF-16BE). (In all cases,
getUTF8Length(), position() and getSubString() will throw a

US-ASCII is used when a user calls PreparedStatement.setAsciiStream()
or ResultSet.updateAsciiStream(). In this case length() and
getByteLength() both return the length in bytes, which is equal to the
length in characters.

UTF-8 is only used internally in NetStatementRequest when sending
VARCHARs or LONGVARCHARs that are more than 32767/3 characters
long. In this case length() and getByteLength() both return the number
of bytes needed to represent the string in UTF-8. These Clob objects
are never exposed to the user.

UnicodeBigUnmarked is never passed to the constructor, but if it were,
length() and getByteLength() would return the length in characters.


Since the return value of the length() method already is inconsistent,
I don't think the patch for lengthless overloads actually makes the
situation much worse. Considering that no other methods work correctly
on these objects anyway (see for instance DERBY-1599), I think fixing
that issue could be done as a separate task.

> 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