db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Date Thu, 04 May 2006 13:55:09 GMT

Daniel John Debrunner wrote:
> Lance J. Andersen wrote:
>> The compliance chapter has seen significant clarifications for JDBC 4 to
>> clarify what is and is not required.  If you implement and interface for
>> a data type such as blob/clob all methods must be implemented otherwise
>> you do not support the data type.
> Is this a recent change to JDBC 4.0? I have a copy dated March 17th 2006
> and I cannot see any significant changes to the Compliance chapter.
I have not release the Proposed Final Draft to the JCP and there have 
been many updates to the compliance chapter since that version you have 
in your hand.
> I do see this sentence (section 6.7 Java EE JDBC compliance):
> "Support for the BLOB, CLOB, ARRAY, REF, STRUCT, and JAVA_OBJECT types
> is not required."
> So, why would full support for Blob be required for JDBC 4.0 compliance,
> if BLOB support is not required for Java EE JDBC and JDBC 4.0 compliance.
It is only required if you claim support for the data type in your 
driver.  What we do not want is you to say u support Clobs but only 
implement the methods on the interface that you happen to like.  We want 
to provide a consistent api where users know what to expect.
> I'm just try to ensure that we are not trying to implement more than is
> required for JDBC 4.0 compliance, if we end up pushing against a Sep/Oct
> deadline for a Derby release with JDBC 4.0.
Again, if you choose to not claim to support these data types, you do 
not need to implement the interfaces

However to claim support and not implement all methods for a given data 
type is of limited value and makes it even more difficult to port apps 
from other databases to a given database
> I'm also asking for reference numbers (e.g. section numbers) as we just
> recently had a problem where the GRANT/REVOKE functional spec stated
> that something was one way according to the SQL spec. It turned out that
> the statement was incorrect, and lead to wasted time & effort. Adding
> references to the specification to backup facts makes it much easier for
> others to verify.
The JDBC spec consists of the paper spec and the javadocs.

The compliance chapter articulates the requirements i list above in the 
working version of the PFD.
> Thanks,
> Dan.

View raw message