db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-499) Expose BOOLEAN datatype to end users
Date Wed, 23 Nov 2005 03:33:42 GMT
Rick Hillegas wrote:

>>> 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.
>> I would have no issue if existing JCC/10.1 network clients continued to
>> report BOOLEAN as SMALLINT, as they seem to. I would have an issue if
>> you changed the current correct behaviour of embedded under jdk 1.3 to
>> match that.
> I will abandon my attempt to simplify the support problem. Instead, I
> will amend the spec as follows: I will add a matrix describing how the
> BOOLEAN datatype will appear to clients based on client and server rev
> and vm.

I think your original direction would cause problems with upwards
compatibility for applications. An embedded application running under
jdk 1.3 would see changes in behaviour when upgrading the VM to Jdk 1.4
or later. This is because api to the BOOLEAN column would change, namely
getObject would change from returning java.lang.Integer (for SMALLINT)
to returning java.lang.Boolean (for BOOLEAN).

I think I see a similar problem with the upcoming XML changes. If we
return XML as CLOB in jdk 1.4 then applications will break when then
switch to the jdk that supports JDBC 4.0. Again for the same reason,
with jdk 1.4 getObject would return java.sql.Clob and in the JDBC 4.0
jdk it would return java.sql.SQLXML. I think for this case
get/setObject() should not succeed for XML columns until JDBC 4.0 is


View raw message