[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Urgency: Normal
Verify that we don't raise SQLFeatureNotSupportedException for mandatory
methods
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Attachment: bug1253_vanishedMethods.diff
Attaching bug1253_vanishedMethods.diff. This makes the UnsupportedVetter test
smart enough to handle methods which
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Attachment: bug1253_wireIn.diff
Attaching bug1253_wireIn.diff. This adds the UnsupportedVetter test to the
jdbc4 test suite. Committed at subversion
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Attachment: bug1253_forwarding.diff
Committed bug1253_forwarding.diff at subversion revision 408772. This patch
forwards some miscellaneous JDBC4 calls to
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Attachment: bug1253_verifier3_complianceChapter.diff
Commmitted bug1253_verifier3_complianceChapter.diff at subversion revision
399482. This modifies the
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Dyre Tjeldvoll updated DERBY-1253:
--
Attachment: derby-1253.v1.diff
derby-1253.v1.stat
Attaching a patch that updates the exclude map with additional interfaces and
methods.
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
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
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
[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
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
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
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Attachment: bug1253_verifier2.diff
Committed bug1253_verifier2.diff at subversion revision 397926. This just
exposes this test (which I have not wired into
[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ]
Rick Hillegas updated DERBY-1253:
-
Attachment: bug1253_verifier.diff
Attaching bug955_verifier.diff, which contains a junit test, UnsupportedVetter.
This test lists out all of the methods
14 matches
Mail list logo