db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Re: JDBC4 Spec exegesis needed, was: [jira] Commented: (DERBY-925) Implement new JDBC 4 metadata API getFunctionParameters()
Date Fri, 03 Mar 2006 18:19:24 GMT
Dyre.Tjeldvoll@Sun.COM wrote:
> 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."

For what it's worth, the ODBC API says this with respect to the metadata methods:

"Applications should bind driver-specific columns relative to the end of the 
result set."

Odd that ODBC says the extra columns should be accessed by position, while JDBC4 
says they should be accessed by name.  Or am I misreading something?  One of the 
arguments for doing it this way is that the column names could change from one 
version to the other--as they have, for example, between ODBC 2.0 and ODBC 3.0...

There is some additional detail at this link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcdata_returned_by_catalog_functions.asp

<begin-quote>

Applications should bind driver-specific columns relative to the end of the 
result set. That is, they should calculate the number of a driver-specific 
column as the number of the last column — retrieved with SQLNumResultCols — less 
the number of columns that occur after the required column. This saves having to 
change the application when new columns are added to the result set in future 
versions of ODBC or the driver. For this scheme to work, drivers must add new 
driver-specific columns before old driver-specific columns so that column 
numbers do not change relative to the end of the result set.

<end-quote>

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

If I'm understanding correctly, that's the argument ODBC makes ;)  I.e. a 
"well-written" app should reference the extra columns by position relative to 
the end of the result set; if they do that, then their apps will still work even 
if there are extra columns at the end--*ASSUMING* that the driver, in turn, does 
its part by adding "new driver-specific columns before old driver-specific 
columns so that column numbers do not change relative to the end of the result set."

Maybe that's all irrelevant, but it seems like the general trend in the metadata 
area is for JDBC to follow ODBC leads (in fact, I think Lance said that very 
thing some time long long ago...?), so I thought I'd mention it.

> But maybe this is all hypothetical... :)

Ditto.

Army


Mime
View raw message