db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-499) Expose BOOLEAN datatype to end users
Date Fri, 09 Dec 2005 02:09:08 GMT
    [ http://issues.apache.org/jira/browse/DERBY-499?page=comments#action_12359837 ] 

Rick Hillegas commented on DERBY-499:

Satheesh, thank you for pointing out the disabling code in the inSelectClause() production.
I will fix this and add appropriate test cases.

Kathey, thank you for going through the network code so carefully. Some responses follow:

0) I understand your misgivings. I do however see some value in rolling some ongoing cleanup
into patches. I tried to steer a middle course here: I moved the datatype ids to a common
file but I deferred the rototill of Typdef.java to a later submission. I hope this is ok.
Please let me know if you think this is a showstopper.

1) I certainly hope that the Open Group will finalize the new datatypes in the 10.2 timeframe.
It's a slow process. I don't see a conflict with Army's work on XML but Army and I can work
together on this.

You are right, that if we include the DRDA types, we should include corresponding DB2 types.
I will add these as more placeholders.

2) Yes, the BOOLEANS are coming from the client as SMALLINT. I agree that it would be better
to send these as booleans. I will make that change. I will also make the other changes you
suggest here.

3) I can add the CrossConverter code you suggest. But I can't answer your question: Obviously
the tests I have written don't stress this code. Can you help me understand what test cases
will stress this code?

4) Thanks for catching this. I will add BOOLEAN to getTypeInfo().

5i) I ran the compatibility suite in the following combinations:

o I allowed the server to range over the following options:,,,
and mainline.
o Each server was run on the following vms: 1.3, 1.4, and 1.5
o For each combination of server and server vm, I allowed the client to range over the following
options: DB2JCC,,, and mainline.
o For each combination of server, server vm, and client, I ran the client on the following
vms: 1.3, 1.4, and 1.5.

In addition, I ran the mainline in an embedded configuration on the following vms: 1.3, 1.4,
and 1.5.

5ii) Thanks for suggesting this. I will add some boolean cases to an existing ij test to verify
formatting. I have already tested with older clients and verified that BOOLEAN goes to old
clients as SMALLINT.

6) Thanks for this suggestion too. I will add boolean cases to jdbcapi/parameterMapping.

7) I welcome your creative suggestions here. The best idea I have been able to come up with
is the running of the compatibility suite as part of some nightly or weekly verification.

> Expose BOOLEAN datatype to end users
> ------------------------------------
>          Key: DERBY-499
>          URL: http://issues.apache.org/jira/browse/DERBY-499
>      Project: Derby
>         Type: New Feature
>   Components: SQL
>     Versions:
>     Reporter: Rick Hillegas
>     Assignee: Rick Hillegas
>  Attachments: BooleanFS.html, bug499.diff, bug499_doc.zip
> Veaceslav Chicu started an email thread on 8 August 2005 titled "boolean type". He was
disappointed that Derby doesn't support the ansi BOOLEAN datatype. On closer inspection, Derby
does internally support this type but does not expose this support to end users.
> Derby should let users declare table columns of type BOOLEAN. This should be an indexable

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message