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: behavior of Statement.getGeneratedKeys()
Date Tue, 11 Jul 2006 05:35:16 GMT
Kathey Marsden wrote:

> Rick Hillegas wrote:
> 
>>>>>>
>>>>>> 1) Is this a bug? Should Statement.getGeneratedKeys() return a
>>>>>> ResultSet whose column has the same type as the underyling
>>>>>> autogenerated column?
>>>>>>
> Reading from the JDBC 3.0 and JDBC  4.0 spec it seems clear to me that
> we are not compliant and if non-compliance is a bug, this is  a bug.  
> The spec says: "Calling ResultSet.getMetaData on the ResultSet object
> returned by getGeneratedKeys will produce a ResultSetMetaData object
> that can be used to determine the number, type and properties of the
> generated keys."

It's not entirely clear to me that Derby is not compliant.

The ResultSetMetaData does correctly described the "number, type and
properties of the generated keys.", ie. it describes the ResultSet
correctly. One could say Derby always generates keys internally as of
type DECIMAL(31, 0) and that is what getGeneratedKeys() returns, but
when it is stored in a column it is mapped to the specific type of that
column.

The spec for the getGeneratedKeys() has always been too vague.

One could even argue that Derby should not return anything because Derby
does not have a mechanism to generate a "*unique* key field" (see first
sentence of 13.6 in JDBC 4). Or maybe Derby should only return values
when the column is generated and is defined to be the sole column for a
primary key constraint (and also unique constraint?).

I guess I'm still curious to the benefit of changing it and am
interested to see if a proposed fix adds or removes complexity (and for
what value).

Dan.



Mime
View raw message