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.
>
>
>   

Mime
View raw message