Return-Path: 
 <derby-dev-return-10859-apmail-db-derby-dev-archive=db.apache.org@db.apache.org>
Delivered-To: apmail-db-derby-dev-archive@www.apache.org
Received: (qmail 5332 invoked from network); 22 Nov 2005 15:32:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 22 Nov 2005 15:32:57 -0000
Received: (qmail 2795 invoked by uid 500); 22 Nov 2005 15:32:51 -0000
Delivered-To: apmail-db-derby-dev-archive@db.apache.org
Received: (qmail 2681 invoked by uid 500); 22 Nov 2005 15:32:50 -0000
Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:derby-dev-help@db.apache.org>
List-Unsubscribe: <mailto:derby-dev-unsubscribe@db.apache.org>
List-Post: <mailto:derby-dev@db.apache.org>
List-Id: <derby-dev.db.apache.org>
Reply-To: <derby-dev@db.apache.org>
Delivered-To: mailing list derby-dev@db.apache.org
Received: (qmail 2651 invoked by uid 99); 22 Nov 2005 15:32:50 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2005 07:32:50 -0800
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2005 07:34:23 -0800
Received: from phys-d3-ha21sca-2 ([129.145.155.165])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jAMFWTD7021134
	for <derby-dev@db.apache.org>; Tue, 22 Nov 2005 08:32:29 -0700 (MST)
Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by
 ha21sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 id <0IQD007014I5YD@ha21sca-mail1.sfbay.sun.com>
 (original mail from Richard.Hillegas@Sun.COM) for derby-dev@db.apache.org;
 Tue, 22 Nov 2005 07:32:57 -0800 (PST)
Received: from [129.150.33.185]
 (vpn-129-150-33-185.Central.Sun.COM [129.150.33.185])
 by ha21sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0IQD00CKW4IW20@ha21sca-mail1.sfbay.sun.com> for
 derby-dev@db.apache.org; Tue, 22 Nov 2005 07:32:57 -0800 (PST)
Date: Tue, 22 Nov 2005 07:32:28 -0800
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-499) Expose BOOLEAN datatype to end users
In-reply-to: <438299D1.1040309@debrunners.com>
To: derby-dev@db.apache.org
Message-id: <43833A0C.5090507@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
References: <2015076743.1132591182460.JavaMail.jira@ajax.apache.org>
 <438299D1.1040309@debrunners.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Hi Dan,

Thanks for your comments. Some responses follow. Cheers-Rick

Daniel John Debrunner wrote:

...

>
>Derby has never supported BOOLEAN, so you are not re-enabling it. This
>might confuse readers of this spec.
>  
>
I will wordsmith this.

>In order to support BOOLEAN data type according to SQL Standard 2003
>(feature T031) boolean literals need to be supported, and <boolean
>literal> includes UNKNOWN
>  
>
UNKNOWN will also be a supported literal. I will note this in the spec.

>In the JDBC api section, I assume it means that this "In all other
>cases, DatabaseMetaData and ResultSetMetaData will report BOOLEAN
>columns as JDBC type java.sql.Types.SMALLINT." means the JDBC typid
>column will be Types.SMALLINT, but the SQL type name will continue to be
>BOOLEAN. E.g. ResultSetMetaData.getColumnNameType() will return
>"BOOLEAN". 
>
I don't understand what it means if type names don't agree with type 
codes. I was planning to report these columns as type code 
java.sql.Types.SMALLINT and type name "SMALLINT".

>Why Types.SMALLINT, and not Types.OTHER or Types.BIT?
>  
>
I chose SMALLINT for a tactical reason:  It is the type currently used 
if the Derby client selects from one of our BOOLEAN-typed system 
columns. I'm hoping that this mapping will have fewer compatibility 
issues for existing applications.

>Can I also assume you meant "ResultSet.getXXX and
>CallableStatement.getXXX" methods?
>  
>
Yes to the question about CallableStatement.getXXX(). I'm afraid I don't 
understand the question about ResultSet.getXXX().

>When you say "... getXXX ... setXXX methods will succeed", what exactly
>does that mean? How do the BOOLEAN values true and false map the
>numeric/string getXXX values, and how do numeric/string values map to
>true/false on the setXXX methods?
>  
>
I will clarify this in the spec.

>"methods will succeed on BOOLEAN columns peeked and poked by Derby 10.2
>clients running on jdk1.4 or higher"
>Can I retrieve/set BOOLEAN values on other clients?
>  
>
Yes. I will clarify this.

>Are you planning to support getObject/setObject?
>  
>
These don't seem to be required by the JDBC spec.  I don't plan to put 
in any extra effort to make these work, but if they work for free, then 
I see no reason to disable them. In any event, when I'm done, I'll 
update the spec to describe how these methods behave.

>Dan.
>
>  
>