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 Wed, 15 Feb 2006 00:13:20 GMT
    [ http://issues.apache.org/jira/browse/DERBY-499?page=comments#action_12366414 ] 

Rick Hillegas commented on DERBY-499:

Hi Kathey,

I agree that this feature is not ready to be exposed to customers and I doubt that I will
find time to finish it by our release date. I think that the server-to-client logic is pretty
solid but I don't want to deal with compatiblity issues related to the unfinished client-to-server
logic. Here I think the problem is that we are sending one-byte values from the server to
the client but we are still sending 2 byte quantities in the other direction. Let me throw
out some options for what we could do:

1) We could back out the patch. I don't know how hard this is. If it's easy, it might be the
best thing to do. Please advise me on this.

2) We could disable the client-to-server compatibility problems by not allowing BOOLEAN as
the type of columns and procedures/functions. Basically we could resurrect the disabling checks
in the parser. For extra credit we could continue to test the new functionality under a tracepoint
to make sure it does not regress as we move forward.

I'm not sure I understand your issue with the metadata. Could you elaborate?

Most of the illegal casts and comparisons are existing problems left over from Cloudscape.
These illegal casts and comparisons occur in 10.1. The original effort to remove the BOOLEAN
datatype was only partially successful. At the end of the day, we can forbid BOOLEAN columns
but we can't remove the fundamental, resolving datatype of the WHERE clause. When considering
bug 887, it is important to not balk at a gnat but swallow a camel. The newly introduced cases
have caused us to stumble across something very old and very broken on which our production
code relies. I don't think we can ignore bug 887 even if we back out 499. In my opinion, the
presence or absence of the 499 code does not affect whether we should fix 887 for release

Let me punch up the importance of this point: Our own production code already relies on pre-existing
illegal casts and comparisons. Quite likely, some of our customers do too.

In summary:

o I think that we should back out user-declarable BOOLEAN columns/args one way or another.

o If (1) and (2) are showstoppers, they are showstoppers regardless of what we do about user-declarable
BOOLEAN columns/args.

> 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, bug499_jdk13tests.diff, bug499_jdk13tests_rev2.diff,
bug499_rev2.diff, bug499_rev3.diff, bug499_rev4.diff, jdk131BooleanFailures.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