db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Missing JDBC3 methods, was: [jira] Updated: (DERBY-1253) Verify that we don't raise SQLFeatureNotSupportedException for mandatory methods
Date Tue, 02 May 2006 21:06:50 GMT
Hi Lance,

Here's another gap between Derby's JDBC3 implementation and a reasonable 
interpretation of the spec: Currently, Derby supports CallableStatement 
methods of the form:

  getXXX( int paramNumber) and
  setXXX( int paramNumber, FOO paramValue )

but Derby does not implement the corresponding CallableStatement methods 
(they throw "Not implemented" exceptions):

  getXXX( String paramName) and
  setXXX( String paramName, FOO paramValue )

Is this asymmetry OK or do you think that methods in the second block 
are mandatory when the corresponding methods in the first block work?

Thanks,
-Rick


Lance J. Andersen wrote:

> 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.
>
> Dyre.Tjeldvoll@Sun.COM wrote:
>
>>"Lance J. Andersen" <Lance.Andersen@Sun.COM> 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 :(
>>
>>  
>>


Mime
View raw message