db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@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 19:15:11 GMT
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:
> 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