db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Binding a char to PreparedStatement
Date Sat, 23 Jul 2005 17:01:00 GMT
Hi Dan,

On Jul 22, 2005, at 1:04 AM, Daniel John Debrunner wrote:

> Craig Russell wrote:
>> Hi Erik,
>> On Jul 21, 2005, at 2:10 AM, erik@jpox.org <mailto:erik@jpox.org>  
>> wrote:
>>> CHAR(1) will not allow Unicode storage, you need either to use  
>>> NCHAR(1),
>>> CHAR(4) or another type that allows you to store 2 bytes.
>> Correct. The point is what should be the default.
> Well, implementation defined really. Derby defines CHAR(1) as storage
> for one *character*, not one byte, character is really the intent  
> of the
> SQL spec. Derby always uses Unicode as the character set, so CHAR 
> (1) can
> store any Unicode character from Java.

The intent of the separate jdbc-type and sql-type is to give the user  
the most flexibility in defining the known constraints of the data in  
the object model mapped to the constraints of the database.

For example, in the JDO TCK, we test the ability of an implementation  
to store the range of valid char values, which for some fields is  
0..65535. We know many databases that don't allow this range to be  
stored as a CHAR(1) even though Derby does. So we specify this as a  
jdbc-type INTEGER.

Other char fields are known to store a smaller range of values, and  
we know that the values can be stored in any database as a single  
byte using any encoding that maps ASCII to one byte. For these  
columns, we use jdbc-type of CHAR and expect to be able to store  
these limited values there.

If we only had to deal with the object model view of the data, it  
would be easier to define the type mapping. But real world databases  
come with their own set of applications already written that define  
the content, and the object model needs to conform to that content.  
So it's inappropriate to always map char to INTEGER, even though we  
know that it would always work for the object model. But other  
applications might have defined the column's data in a different way.

> Dan.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message