db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: JDBC4 Spec exegesis needed, was: [jira] Commented: (DERBY-925) Implement new JDBC 4 metadata API getFunctionParameters()
Date Fri, 03 Mar 2006 18:03:26 GMT
Daniel John Debrunner <djd@apache.org> writes:

> 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?
>
> JDBC tutorial & reference, version 2.0, sdection 15.2.2, page 369 says:
>
> "A DBMS may define additional columns for a ResultSet object that is
> returned by a DatabaseMetaData method".

On a related note, getProcedureColumns() already does that today. The
returned result set has two additional columns (METHOD_ID &
PARAMETER_ID) that aren't part of the spec. This does not seem to
cause any problems, but where should these two columns go when we add
7 new JDBC4 columns to the result set? 

The JDBC4 javadoc says:

"Additional columns beyond SPECIFIC_NAME can be defined by the
database and must be accessed by their column name."

Does that mean it is safe to put these extra columns at the end? Will
that not potentially break existing applications? One could argue that
only poorly written apps will have a problem with this I suppose, but
still...

These two columns are also used to order the result set:

...
ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, METHOD_ID, PARAMETER_ID

The JDBC4 javadoc states that

"They are ordered by PROCEDURE_SCHEM, PROCEDURE_NAME and SPECIFIC_NAME." 

So if we keep the existing ordering we're not compliant, but if we
change it we risk breaking clients that rely on the existing ordering.

But maybe this is all hypothetical... :)

-- 
dt

Mime
View raw message