db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernanda Pizzorno (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-477) JDBC client and embedded drivers differ wrt API subset supported
Date Tue, 16 Aug 2005 13:13:54 GMT
    [ http://issues.apache.org/jira/browse/DERBY-477?page=comments#action_12318888 ] 

Fernanda Pizzorno commented on DERBY-477:

relative(int rows) behaves different in embedded and client/server mode when the positioning
before the first row or after the last row.

The embedded driver shows the behaviour described in the JDBC 3.0 specification, returning
false and postitioning in either before first or after last. While the client/server driver
returns true and incrementing/decrementing the current row by "rows" and not setting the position
to either before first of after last.

I have run a test with a result set with 10 rows, where I positioned in row 5 and moved +20
and - 20 using relative(int rows). With the embedded driver the method returned false, the
current row was set to 0 and isAfterLast() and isBeforeFirst() returned true (for +20 and
-20 respectively). With the client/server driver the method returned true, the current row
was set to 25 and -15 (for +20 and -20 respectively) and isAfterLast() and isBeforeFirst()
returned false.

> JDBC client and embedded drivers differ wrt API subset supported
> ----------------------------------------------------------------
>          Key: DERBY-477
>          URL: http://issues.apache.org/jira/browse/DERBY-477
>      Project: Derby
>         Type: Improvement
>   Components: JDBC, Network Client, Network Server
>     Versions:,,
>     Reporter: Dag H. Wanvik
>  Attachments: api-diffs.txt
> After having noticed some differences (mail url below) in Clob and
> Blob support, I did a walkthough of both drivers of things marked as
> "not implemented", "not supported", etc., to see how they align.
> [http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/%3c17111.57879.760051.226994@sun.com%3e],
> Below is a summary of my findings. I attach a file "api-diffs.txt"
> which shows all "not implemented" methods in the interfaces I looked
> at, also for those cases where the drivers are in agreement.
> Caveat 1: This is all based on visual inspection of the code only.
> Caveat 2: I mostly looked at the top-level API implementation code, so
> there may be cases where the cut-off occurs at a lower level in the
> code which I missed.
> Caveat 3: The client uses lots of different strings to signal that a
> method us not implemented; e.g. "Driver not capable", "Driver not
> capable": X", "Driver no capable" (sic), "not supported by server",
> "under construction", "JDBC 3 method called - not yet supported",
> "jdbc 2 method not yet implemented", "X is not supported". I may have
> missed some...
> On each line I list the method with signature, and status for the
> embedded driver and the client driver, in that order. I use "NI" to
> mark not implemented, and a "+" to mark (apparently) implemented.
> The next step should be to check the tests and the documentation, as
> soon as we agree on how the harminization should be carried out.
>                                                           Embedded Client
> Resultset#                                      
> getUnicodeStream(int columnIndex)                               NI   +
> getUnicodeStream(String columnName)                             NI   +
> updateBlob(int columnIndex, Blob x)                             +   NI
> updateBlob(String columnName, Blob x)                           +   NI
> updateClob(int columnIndex, Clob x)                             +   NI
> updateClob(String columnName, Clob x)                           +   NI
> CallableStatement#   
> getBlob(int i)                                                  NI   +   
> getBytes(int parameterIndex)                                    NI   + 
> getClob(int i)                                                  NI   + 
> registerOutParameter(int paramIndex, int sqlType,                                   
>                                  String typeName)               NI   +²
> ²bug:does nothing!
> Should be filed as separate bug?
> Blob#
> setBinaryStream(long pos)                                       NI   +¹  
> setBytes(long pos, byte[] bytes)                                NI   +   
> setBytes(long pos, byte[] bytes, int offset, int len)           NI   +   
> truncate(long len)                                              NI   +   
> ¹bug reported by Laurentz Albe
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/%3c859414957.1121432109873.JavaMail.jira@ajax.apache.org%3e
> Should be filed as separate bug?
> Clob#
> setAsciiStream(long pos)                                        NI   +  
> setCharacterStream(long pos)                                    NI   +  
> setString(long pos, String str)                                 NI   +  
> setString(long pos, String str, int offset, int len)            NI   +  
> truncate(long len)                                              NI   +  
> PreparedStatement#
> setNull(int paramIndex, int sqlType, String typeName)           NI   +³
> setUnicodeStream(int parameterIndex, InputStream x, int length) NI   +
> ³bug: ignores typename
> Should be filed as separate bug?
> DatabaseMetaData#
> getSuperTables(String catalog, String schemaPattern, 
>                String tableNamePattern)                         NI  +
> getSuperTypes(String catalog, String schemaPattern, 
>               String typeNamePattern)                           NI  +
> locatorsUpdateCopy()                                            NI  +
> getAttributes(String catalog, String schemaPattern, 
>               String typeNamePattern, 
>               String attributeNamePattern)                      NI  +

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message