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: behavior of Statement.getGeneratedKeys()
Date Tue, 11 Jul 2006 12:38:34 GMT

> 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.

View raw message