db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: behavior of Statement.getGeneratedKeys()
Date Tue, 11 Jul 2006 13:57:43 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."
>
>>>>>> 2) If this is a bug, is it permitted to change this behavior in a
>>>>>> minor release?
>>>>>>
>
> Of course debate continues,  but I think it would be first good to 
> objectively assess what JDBC calls might be affected.    Perhaps 
> whomever is considering making this change could do  a  thorough 
> analysis and present it to the community. After that we could use this 
> issue as a test case for  our goal  at 
> http://wiki.apache.org/db-derby/ForwardCompatibility  as we look at 
> potential risk and what level of consultation is needed with the user 
> community for the change and when it is appropriate.  It should be a 
> good test as our current documented behavior and the spec are at odds.

Hi Kathey,

I'm muddled. The affected JDBC call is Statement.getGeneratedKeys(). I 
don't think anyone is proposing to change the behavior of any other JDBC 
call. But your question makes me anxious. Why do you think other JDBC 
calls are affected?

>
> Kathey
>
>


Mime
View raw message