Hi Dyre,

yes that is correct, if you are supporting those data types it is expected that the required methods are there in order to provide developers with a consistent set of methods.  It does not make sense to just pick and choose especially seeing these data types have been around in JDBC for quite some time now.  Lack of support will make it much more difficult for users to migrate from other backends which support those data types to Derby.

[EMAIL PROTECTED] wrote:
"Lance J. Andersen" <[EMAIL PROTECTED]> writes:

  
If you support a data type such as Blob/Clob, you must implement all
methods on the interface, not pick and choose.

If your backend does not support the data type, then all methods
should throw SQLFeatureNotSupportedException.

This was a problem in the earlier JDBC specs as it did not clarify
which methods were required and which were not.
    

Hi Lance, thanks for the clarification. 

Currently we are missing:

Blob.getBinaryStream(long,long)
Blob.setBinaryStream(long)
Blob.setBytes(long, byte[])
Blob.setBytes(long, byte[], int, int)
Blob.truncate(long)
Blob.free() {DERBY-1145}

Clob.getCharacterStream(long,long) 
Clob.setAsciiStream(long)
Clob.setCharacterStream(long)
Clob.setString(long, String)
Clob.setString(long, String, int, int)
Clob.truncate(long)
Clob.free() {DERBY-1145}


I assume that this means that we also need to implement:

Connection.create[BC]lob()
PreparedStatement.set[BC]lob()
CallableStatement.set[BC]lob() (except named parameter variants)
CallableStatement.get[BC]lob() (except named parameter variants) ?

If so; there is indeed much work that needs to be done before Derby
can claim to support Blob/Clob in Jdbc4 :(

  

Reply via email to