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 Mon, 10 Jul 2006 21:21:38 GMT

Kathey Marsden wrote:
> Rick Hillegas wrote:
>> Hi Kathey,
>> My gut feeling is that changing this behavior could affect 
>> applications like ij which make formatting decisions based on the 
>> JDBC types of returned columns.
If you return the correct column type of the base type, then the 
formatting would be correct.
> I agree, but I am not sure yet how significant that impact might be. 
> I'd like translate it into exactly what JDBC calls will have different 
> behavior in order to more accurately assess the risk in  typical usage 
> scenarios.
> Certainly there are these changes for the ResultSet returned by 
> getGeneratedKeys():
> o  getMetaData()  would  correspond to the ResultSetMetadata of the 
> base table column and so will have different types, columnwidths etc, 
> so formatting and other decisions based on this information may be 
> affected.
Portable code would adjust accordingly to the correct width.  This is 
what a tool would do.
> o  getObject()  would  return a different type and applications making 
> casts based on the assumption it is a BigDecimal  may see cast 
> exceptions or other problematic behavior because of this assumption.
Or because you are returning a BigDecimal when someone is not expecting 
it, you also have problematic behavior.  This fact is buried in the 
Derby docs currently.
> o getString()  would return a different String representation which  
> might  be problematic if a particular format was expected and  parsed.
This would be bad  user code if you depended on getString for a numeric 
value of any type to be consistent.
> Would other ResultSet methods might be affected?  For instance,  would 
> getInt(), getLong(), getShort()  etc. all still work as they did 
> before and return the same values?
> Of course there is the other question still outstanding:
Why would these methods be effected, they have nothing to do with this.

> What  usage cases would *benefit*  from changing it?  This is 
> important,  because if there is no real benefit to changing it  why 
> take the risk at all?
Well the issue is that this behavior is not expected that you are 
returning a different data type then the column in the table. 

> Kathey

View raw message