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
