We had a long EG discussion on this and the wording changes was the only
way we could provide portability and extendability going forward.
Having vendors just throw their own entries into the ResultSet is not
very portable either nor is the ODBC way of changing column names which
is something we chose not to do for JDBC.
-lance
Army wrote:
[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
