Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 03 Mar 2006 14:18:23 -0500
From: "Lance J. Andersen" <Lance.Andersen@Sun.COM>
Subject: Re: JDBC4 Spec exegesis needed,
 was: [jira] Commented: (DERBY-925) Implement new JDBC 4 metadata API
 getFunctionParameters()
In-reply-to: <4408748F.50904@sun.com>
Sender: Lance.Andersen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4408967F.4060407@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References: <2124723271.1141384732886.JavaMail.jira@ajax.apache.org>
 <4408748F.50904@sun.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)

Hi Rick,

There is a limited number of DatabaseMetaData methods have allowed this 
to occur as part of the functionality.  This was unfortunate IMHO.

-lance

Rick Hillegas wrote:
> 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.
>>>   
>>
>>  
>>
>