db-derby-dev mailing list archives

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

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

And that's all they are used for, basically internal use. There is no
exernal documentation saying these columns exist or what they mean so I
don't think applications can be seen to be relying on them. Thus I then
they can be moved to the end, without breaking existing applications.

I think there are really there to stop the test output being
inconsistent. It may not be relevant now, it did when a procedure meant
a Cloudscape method alias which mapped to a set of Java methods. The
parameters for this method were found using reflection and the ordering
of infomation from reflection is not guaranteed, leading to different
ordering on different JVMs.

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

The only ordering clients should be relying on, is that documented by
the DatabaseMetadata which for JDBC 3.0 is PROCEDURE_SCHEM, PROCEDURE_NAME.

So changing the ordering to this would be compatible with JDBC 3.0 and
JDBC 4.0 and applications that are written against the specs.

ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, SPECIFIC_NAME, METHOD_ID,
PARAMETER_ID

A different issue could be investigating if we still need the additional
ordering now that Derby only supports well defined procedures and not
method aliases.

Thanks for looking into this Dyre.
Dan.




Mime
View raw message