Hi Rick,
named parameters are optional WRT CallableStatements but they need to
throw SQLFeatureNotSupportedException.
This is also clarified in the JDBC 4 spec compliance chapter
Rick Hillegas wrote:
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.
[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 :(
