db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-925) Implement new JDBC 4 metadata API getFunctionParameters()
Date Fri, 03 Mar 2006 13:01:45 GMT
    [ http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368708 ] 

Knut Anders Hatlen commented on DERBY-925:
------------------------------------------

Dyre wrote:

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

I don't think it is necessary have a separate JDBC4
implementation. The 13 columns specified by JDBC3 have not changed in
JDBC4, so I would say that you could just add the seven columns that
are new in JDBC4 and return the same result regardless of JDBC
version. I can't see why any application should rely on
getProcedureColumns() returning a result set with exactly 13
columns. The current Derby implementation of getProcedureColumns()
returns 15 columns, so if returning 20 columns would break it, it's
probably already broken.


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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message