Description
The JDBC spec partially defines the expected behavior of ResultSet.getBoolean(). It would be good to have a regression test which tracks Derby's actual implementation. For the moment, it appears that Derby conforms to the defined behavior, does something reasonable in the undefined cases, and behaves the same way in the embedded and client drivers.
The behavior of ResultSet.getBoolean() does not appear to have been defined until JDBC 4. Here is the JDBC 4 javadoc:
"If the designated column has a datatype of CHAR or VARCHAR and contains a "0" or has a datatype of BIT, TINYINT, SMALLINT, INTEGER or BIGINT and contains a 0, a value of false is returned. If the designated column has a datatype of CHAR or VARCHAR and contains a "1" or has a datatype of BIT, TINYINT, SMALLINT, INTEGER or BIGINT and contains a 1, a value of true is returned."
The behavior for those datatypes is not specified if the actual value is not 0 or 1. However, in a private communication I have the following statement of intent from Lance Andersen, the JDBC spec lead:
"Note: Please refer to your driver documentation for the return value when the designated column contains a values other than "0", 0, "1" or 1."
In addition, the behavior for other datatypes is not specified. Some day it might be good if Derby's documentation described our behavior in the unspecified cases. Here it is:
1) ResultSet.getBoolean() on LONG VARCHAR behaves like CHAR and VARCHAR
2) ResultSet.getBoolean() on DECIMAL, REAL, DOUBLE, and NUMERIC behaves like INTEGER.
3) Derby raises an exception if you call ResultSet.getBoolean() on BLOB, CHAR FOR BIT DATA, CLOB, DATE, LONG VARCHAR FOR BIT DATA, TIME, TIMESTAMP, or VARCHAR FOR BIT DATA.
4) You can't even directly select an XML value.
Attachments
Attachments
Issue Links
- relates to
-
DERBY-499 Expose BOOLEAN datatype to end users
-
- Closed
-