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: Mon, 10 Jul 2006 21:04:40 -0400
From: "Lance J. Andersen" <Lance.Andersen@Sun.COM>
Subject: Re: behavior of Statement.getGeneratedKeys()
In-reply-to: <44B2D393.8080703@apache.org>
Sender: Lance.Andersen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <44B2F928.7000007@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_ALqGsHSyN7gGbESUKcIAqQ)"
References: <44B29397.4030608@sun.com> <44B2A411.3050000@sbcglobal.net>
 <44B2B783.1090102@sun.com> <44B2C2D6.8010700@sbcglobal.net>
 <44B2C4E2.3060200@sun.com> <44B2D393.8080703@apache.org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)

This is a multi-part message in MIME format.

--Boundary_(ID_ALqGsHSyN7gGbESUKcIAqQ)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT


Daniel John Debrunner wrote:
> Lance J. Andersen wrote:
>
>   
>> Kathey Marsden wrote:
>>
>>     
>>> Rick Hillegas wrote:
>>>       
>
>   
>>> Certainly there are these changes for the ResultSet returned by
>>> getGeneratedKeys():
>>>
>>> o  getMetaData()  would  correspond to the ResultSetMetadata of the
>>> base table column and so will have different types, columnwidths etc,
>>> so formatting and other decisions based on this information may be
>>> affected.
>>>       
>> Portable code would adjust accordingly to the correct width.  This is
>> what a tool would do.
>>
>>     
>>> o  getObject()  would  return a different type and applications making
>>> casts based on the assumption it is a BigDecimal  may see cast
>>> exceptions or other problematic behavior because of this assumption.
>>>       
>> Or because you are returning a BigDecimal when someone is not expecting
>> it, you also have problematic behavior.  This fact is buried in the
>> Derby docs currently.
>>     
>
> Well portable code would adjust accordingly to the type of the returned
> object. :-)
>   
Possibly,   but if getColumns() tells me that the column is  defined as 
an Integer in the table then and  it is also reasonable to expect 
getGeneratedKeys() to return me an Integer.
> Dan.
>
>
>
>   

--Boundary_(ID_ALqGsHSyN7gGbESUKcIAqQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Daniel John Debrunner wrote:
<blockquote cite="mid44B2D393.8080703@apache.org" type="cite">
  <pre wrap="">Lance J. Andersen wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Kathey Marsden wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Rick Hillegas wrote:
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Certainly there are these changes for the ResultSet returned by
getGeneratedKeys():

o  getMetaData()  would  correspond to the ResultSetMetadata of the
base table column and so will have different types, columnwidths etc,
so formatting and other decisions based on this information may be
affected.
      </pre>
    </blockquote>
    <pre wrap="">Portable code would adjust accordingly to the correct width.  This is
what a tool would do.

    </pre>
    <blockquote type="cite">
      <pre wrap="">o  getObject()  would  return a different type and applications making
casts based on the assumption it is a BigDecimal  may see cast
exceptions or other problematic behavior because of this assumption.
      </pre>
    </blockquote>
    <pre wrap="">Or because you are returning a BigDecimal when someone is not expecting
it, you also have problematic behavior.  This fact is buried in the
Derby docs currently.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well portable code would adjust accordingly to the type of the returned
object. :-)
  </pre>
</blockquote>
Possibly,&nbsp;&nbsp; but if getColumns() tells me that the column is&nbsp; defined as
an Integer in the table then and&nbsp; it is also reasonable to expect
getGeneratedKeys() to return me an Integer.<br>
<blockquote cite="mid44B2D393.8080703@apache.org" type="cite">
  <pre wrap="">
Dan.


  </pre>
</blockquote>
</body>
</html>

--Boundary_(ID_ALqGsHSyN7gGbESUKcIAqQ)--