Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 13 Jul 2006 17:35:55 -0400
From: "Lance J. Andersen" <Lance.Andersen@Sun.COM>
Subject: Re: behavior of Statement.getGeneratedKeys()
In-reply-to: <44B6B96F.3060405@sbcglobal.net>
Sender: Lance.Andersen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <44B6BCBB.7080309@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <44B29397.4030608@sun.com> <44B2A411.3050000@sbcglobal.net>
 <44B2B783.1090102@sun.com> <44B2CE1F.4030800@apache.org>
 <44B2E248.3080904@sun.com> <44B332CF.6000604@sbcglobal.net>
 <44B33894.4070008@apache.org> <44B3BDE6.4020801@sun.com>
 <44B40B2C.2000708@sbcglobal.net> <44B412FA.1080304@sun.com>
 <44B67C23.5030803@sun.com> <44B6B96F.3060405@sbcglobal.net>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)


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
>