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:
>  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:
For more information on JIRA, see:

View raw message