[ 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 10.2. 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: 10.1.1.0 > 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 datatype. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
