...


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".

I think that's wrong, the SQL name/type of the column is BOOLEAN, not
SMALLINT. As for "type names don't agree with type codes", I'm not sure
what you mean by agree, these are two different type domains, JDBC for
the Types.XXX values and SQL for the SQL names. The JDBC driver is
providing a mapping between domains, there is not any requirement for
agreement in names to ids.
You are right. That's what the javadoc says. I will update the spec to say that getColumnTypeName() will return the string "BOOLEAN" for BOOLEAN-typed columns.


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.

Does the embedded driver report these columns as SMALLINT? Types.BIT was
the recommended value for BOOLEAN SQL types in JDBC 2, look at the Java
type to JDBC type mapping for Types.BIT.
It depends on what rev level you're running at. Here are the cases:

Embedded on jdk1.3:

   DatabaseMetaData:  java.sql.Types.BIT (called "BOOLEAN")
   ResultSetMetaData: java.sql.Types.BIT (called "BOOLEAN")

Embedded on jdk1.4:

   DatabaseMetaData:  java.sql.Types.BOOLEAN (called "BOOLEAN")
   ResultSetMetaData: java.sql.Types.BOOLEAN (called "BOOLEAN")

Client on jdk1.3/1.4 against server on jdk1.3:

   DatabaseMetaData:  java.sql.Types.BIT (called "BOOLEAN")
   ResultSetMetaData: java.sql.Types.SMALLINT (called "SMALLINT")

Client on jdk1.3/jdk1.4 against server on jdk1.4:

   DatabaseMetaData:  java.sql.Types.BOOLEAN (called "BOOLEAN")
   ResultSetMetaData: java.sql.Types.SMALLINT (called "SMALLINT")


I'm hoping that this mapping will have fewer compatibility
issues for existing applications.

So I assume you mean existing applications from other databases that
currently support BOOLEAN SQL type. Do you know what JDBC type id those
databases return?

I was concerned about compatibiltiy with existing Derby-enabled applications running on previous Derby revs or old VMs.

Unfortunately, there are two other type systems hidden in our network layer: DRDA data value formats and DB2 type ids. I am skeptical that we could get old Derby clients to handle BIT datatypes and values correctly.

I am trying to avoid an explosion of cases because I think that will cause a lot of support headaches. The simplification I was hoping for was one set of behaviors governing clients/servers operating at the current Derby and JDBC rev level and another set of behaviors for all other combinations.

Reply via email to