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-925) Implement new JDBC 4 metadata API getFunctionParameters()
Date Fri, 03 Mar 2006 19:04:10 GMT
No revisions to getFunctionParameters.  this was settled in Dec, just EG 
confusion.  Only thing i changed was the constant 
functionParameterReturn to functionReturn as i missed this earlier.

-lance

David W. Van Couvering wrote:
> I have noticed on the JDBC4 EG mailing list that this method appears 
> to be going through revisions.  Lance, do you have the latest on this?
>
> David
>
> 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