[ 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: 10.0.2.1, 10.1.1.0, 10.1.2.0, 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, 10.1.1.0, 10.1.2.0, 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: 10.1.1.0 > 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 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
