It's not entirely clear to me that Derby is not compliant.
I do not believe i indicated it was or was not compliant, my point was
is the data type is not what i would expect returned in this scenario.
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 question is why did you decide to do return a data type other then
the type of the column that it was defined? This is a more
useful thing to discuss instead of just trying to find means to say it
is not a Derby problem and Derby is correct.
The spec for the getGeneratedKeys() has always been too vague.
I won't deny that this could be written better, but this was done before
my time and in reality, i do not think you will find a spec out there
which does not have areas for clarification.
There is a process for requesting improvements in the spec one way is
you can log a bug via java.sun.com for a Sun lead spec or send an email
to the comments alias for the spec in question. This
would be the best way to get clarifications done to the specs.
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?).
Again this is the original wording going back to JDBC 3. I can look
at trying to clarify this a bit for the final version of JDBC 4, but not
for the PFD. No promises at this time.
This still does answer why DECIMAL(31,0) was chosen as the return type
to be returned in all cases? Understanding this question would help in
determining what action if any is needed.
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).
The one benefit is consistency, you define an Integer, i get an Integer
back which represents what was stored in the database.
On the flip side, what is the real risk in changing the behavior?
Whatever you decide for Derby, the Derby documentation needs clarified
as well.
We all want Derby to be successful and be the best product it can be.
Dan.
