db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: behavior of Statement.getGeneratedKeys()
Date Thu, 13 Jul 2006 21:35:55 GMT


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
>

Mime
View raw message