[EMAIL PROTECTED] 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
