Mamta Satoor wrote:

Hi Army,

I could be wrong about this but if we change metadata.properties to return JDBC 3 result sets,
then won't that be incorrect result sets when running JDBC 2 jdk?


"A B (JIRA)" wrote:


NOTES:
JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to 
just modify metadata.properties to return JDBC 3 result sets...

That was my first thought, too.  But then I saw this paragraph in the "Goals" 
section of the JDBC 3.0 spec:

[ begin quote ]

9. Maintain backward compatibility with existing applications and drivers

Existing JDBC technology-enabled drivers ("JDBC drivers") and the applications that use them must continue to work in an implementation of the Java virtual machine that supports the JDBC 3.0 API. Applications that use only features defined in earlier releases of the JDBC API, excluding those that were deprecated by JDBC 2.0, will not require changes to continue running. It should be straightforward for existing applications to migrate to JDBC 3.0 technology.

[ end quote ]

I also noticed the following little snippet from a web site on JDBC 3.0 (http://www-106.ibm.com/developerworks/java/library/j-jdbcnew/):

[ begin quote ]

Design Goals

The JDBC 3.0 specification is set forth primarily to round out the feature set 
of prior JDBC specifications. Consequently, one of the guiding design 
principles of the new specification is to maintain compatibility with existing 
applications and drivers. Therefore, users of JDBC 2 can expect their 
applications to function correctly under JDBC 3.0. Additionally, code written 
to the JDBC 1 API that uses the previously deprecated methods will continue to 
work.

[ end quote ]

I admit that I didn't investigate these paragraphs any further, so maybe there's more to be learned than what I 
originally took from them.  For example, even if a JDBC 2 application does in fact "function correctly under JDBC 
3.0", does that imply that a database which returns JDBC 3.0 metadata is still "JDBC 2 compliant"?  I.e. 
"function correctly" doesn't necessarily equal "JDBC 2 compliant", so maybe you're right--perhaps 
the fix is more complicated than the NOTE in the JIRA entry suggests...

Any one out there know for sure?
Army




Reply via email to