db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject JDBC4 Spec exegesis needed, was: [jira] Commented: (DERBY-925) Implement new JDBC 4 metadata API getFunctionParameters()
Date Fri, 03 Mar 2006 16:53:35 GMT
Hi Lance,

Is it OK for a JDBC3 implementation to return more information than the 
spec demands? In particular, consider the various result sets returned 
by DatabaseMetaData calls. Is it OK for these result sets to contain 
additional, trailing columns, above and beyond the columns required by 
the JDBC3 spec? To be even more pedantic, can JDBC3 implementations 
return the fatter JDBC4 result sets?

Thanks,
-Rick

Dyre Tjeldvoll (JIRA) wrote:

>    [ http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368699 ] 
>
>Dyre Tjeldvoll commented on DERBY-925:
>--------------------------------------
>
>I just realized that DatabaseMetaData.getProcedureColumns() has been changed in JDBC 4.0.
The result set it returns now conatains a number of new columns and is, in fact, a super set
of the columns returned by getFunctionParameters. For JDBC 4.0 it will likely be necessary
to extend the existing GetProcedureColumns.java VTI with much of the same information that
I was thinking about putting into the new VTI. Perhaps both methods can be implemented with
queries against a single VTI? We will probably need a separate getProcedureColumns40 query
in metadata.properties to maintain backward compatibility?
>
>  
>
>>Implement new JDBC 4 metadata API getFunctionParameters()
>>---------------------------------------------------------
>>
>>         Key: DERBY-925
>>         URL: http://issues.apache.org/jira/browse/DERBY-925
>>     Project: Derby
>>        Type: New Feature
>>  Components: JDBC
>>    Versions: 10.2.0.0
>> Environment: JDK 1.6
>>    Reporter: David Van Couvering
>>    Assignee: Dyre Tjeldvoll
>> Attachments: TypePrinter.java
>>
>>I am currently implementing this to return an empty result set so at least we're compliant,
but we should be able to provide real metadata here.
>>    
>>
>
>  
>


Mime
View raw message