Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some responses follow. Cheers-Rick
Daniel John Debrunner wrote:
...
Derby has never supported BOOLEAN, so you are not re-enabling it. This
might confuse readers of this spec.
I will wordsmith this.
In order to support BOOLEAN data type according to SQL Standard 2003
(feature T031) boolean literals need to be supported, and <boolean
literal> includes UNKNOWN
UNKNOWN will also be a supported literal. I will note this in the spec.
In the JDBC api section, I assume it means that this "In all other
cases, DatabaseMetaData and ResultSetMetaData will report BOOLEAN
columns as JDBC type java.sql.Types.SMALLINT." means the JDBC typid
column will be Types.SMALLINT, but the SQL type name will continue to be
BOOLEAN. E.g. ResultSetMetaData.getColumnNameType() will return
"BOOLEAN".
I don't understand what it means if type names don't agree with type
codes. I was planning to report these columns as type code
java.sql.Types.SMALLINT and type name "SMALLINT".
Why Types.SMALLINT, and not Types.OTHER or Types.BIT?
I chose SMALLINT for a tactical reason: It is the type currently used
if the Derby client selects from one of our BOOLEAN-typed system
columns. I'm hoping that this mapping will have fewer compatibility
issues for existing applications.
Can I also assume you meant "ResultSet.getXXX and
CallableStatement.getXXX" methods?
Yes to the question about CallableStatement.getXXX(). I'm afraid I
don't understand the question about ResultSet.getXXX().
When you say "... getXXX ... setXXX methods will succeed", what exactly
does that mean? How do the BOOLEAN values true and false map the
numeric/string getXXX values, and how do numeric/string values map to
true/false on the setXXX methods?
I will clarify this in the spec.
"methods will succeed on BOOLEAN columns peeked and poked by Derby 10.2
clients running on jdk1.4 or higher"
Can I retrieve/set BOOLEAN values on other clients?
Yes. I will clarify this.
Are you planning to support getObject/setObject?
These don't seem to be required by the JDBC spec. I don't plan to put
in any extra effort to make these work, but if they work for free,
then I see no reason to disable them. In any event, when I'm done,
I'll update the spec to describe how these methods behave.
They are required, it was a bug in pre-jdbc 4. See the EDR2 for jdbc 4
Dan.
