Lance J. Andersen wrote:
This issue pointed out a problem in the JDBC EoD RI which made the
assumption that the value returned matched the column type in the base
table.
A Derby user encountered this issue as well, trying to use 10.2 and
JDBC EoD http://binkley.blogspot.com/2006/04/nifty-jdbc-40.html.
So here is a benefit. The change may ease migration to Derby for apps
that make this assumption. I hit a similar thing recently that Derby
Clob.getSubString does not support a zero offset and DDLUtils expected
it to. (That one is still on my list to file. I don't know yet if that
is a Derby bug or not. ) Another similar case is DERBY-1501 where it
would be nice if Derby were more forgiving of non-portable apps. Of
course in both of those other cases we would just be adding to existing
support, not changing existing behavior and `there is a risk to apps
that develop on Derby and expect to be able to move without changes to
another db.
Anyway I think if you would like to make this change it would be
reasonable to file a Jira issue and pursue due diligence with the user
community. I'll get in touch with some of the users I work with and
see if it might be an issue, but if limited to what has been outlined so
far I tend to think it won't conflict with most typical usage cases. I
think that basically folks are going to be calling getLong() or getInt()
on the ResultSet returned and not getObject. If they are looking at
the metadata they are expecting it to be as you describe. But I will
wait until we hear more.
My biggest concerns with the change are:
1) The precedent it sets. That we can change compliant, documented
behaviour like this. But reading the ForwadCompatibility goal I feel
reassured that maybe this is ok.
"The goal is to allow any application written against the public
interfaces of an older version of Derby to run, without any changes,
against a newer version of Derby."
Maybe though, the ForwardCompatiblity guidelines should have information
on due dilligence when making an incompatible change.
2) The potential high risk and impact of the code change for
client/server as outlined in my earlier mail.
Kathey
- Re: behavior of Statement.getGeneratedKeys() Kathey Marsden
-
