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 Thu, 13 Jul 2006 21:21:51 GMT
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.


View raw message