Kathey Marsden wrote:
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.
Well, it appears that the behavior in Derby was copied from the IBM DB2
driver i am afraid, which did not come up on my EG call discussion
yesterday as a difference in behavior, but that happens as well without
sometimes specifically testing. Nothing sadly is ever easy is it...
So here is a benefit. The change may ease migration to Derby for
apps that make this assumption.
It would help with some databases such as Oracle for sure.
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.
Understand, the original intent of this thread was also to try and
understand why this behavior was there and know i know.
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
