db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-499) Expose BOOLEAN datatype to end users
Date Tue, 22 Nov 2005 22:57:48 GMT

...

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

Mime
View raw message