db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: behavior of Statement.getGeneratedKeys()
Date Mon, 10 Jul 2006 21:12:54 GMT
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.
>
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.
 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.
o getString()  would return a different String representation which  
might  be problematic if a particular format was expected and  parsed.

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:
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?

Kathey



Mime
View raw message