db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-477) JDBC client and embedded drivers differ wrt API subset supported
Date Mon, 17 Aug 2009 12:30:15 GMT

    [ https://issues.apache.org/jira/browse/DERBY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744039#action_12744039

Knut Anders Hatlen commented on DERBY-477:

DERBY-2443 implemented embedded ResultSet.updateBlob/updateClob.
DERBY-2247 implemented all the Blob methods.
DERBY-2800 and DERBY-2346 implemented all the Clob methods.
DERBY-1493 implemented embedded PreparedStatement.setNull(int,int,String), and like the client
implementation it ignores the type name.
DERBY-968 implemented the remaining embedded DatabaseMetaData methods.
EmbedCallableStatement.getBytes(int) is (and has always been) implemented, so it was probably
included in the list by mistake.

That leaves us with one remaining issue: CallableStatement.getBlob(int) and CallableStatement.getClob(int)
are not implemented on the embedded driver.

Should we open a separate issue for those two methods and close this issue?

> JDBC client and embedded drivers differ wrt API subset supported
> ----------------------------------------------------------------
>                 Key: DERBY-477
>                 URL: https://issues.apache.org/jira/browse/DERBY-477
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Network Client, Network Server
>    Affects 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.
You can reply to this email to add a comment to the issue online.

View raw message