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 Fri, 22 Jul 2005 02:04:34 GMT
Hi Erik,

On Jul 21, 2005, at 2:10 AM, erik@jpox.org wrote:

> See inline
>
> Erik Bengtson
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM]
> Sent: Thursday, July 21, 2005 12:26 AM
> To: jdo-dev@db.apache.org
> Subject: Re: Binding a char to PreparedStatement
>
>
>> I was thinking that most of the value in the jdbc-type would be in  
>> the
>> java-to-database schema creation, where the user could rely on the  
>> jdo
>> impl to create appropriate schema. In the case of char or >Character,
>> that would be CHAR(1). In the case of double or Double, with a  
>> length of
>> 20 and a scale of 12, that would be DOUBLE if the database  
>> supported it,
>> or DECIMAL(20, 12) if not.
>
> 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. I believe that if  
you are using a single-byte character encoding like Latin or well,  
some others, that this is sufficient. And columns that need to  
accommodate national use characters are usually well-known by the  
application. I believe if the application has to store wide  
characters, it's ok for the user to have to tell the JDO metadata  
that you want an INTEGER to store these single characters.

> We use INTEGER
> data type by default which works in all databases, and more, it allows
> operators like > < on SQL queries without having to convert it using
> ASCII functions.

Unfortunately, using < and > on SQL queries of characters converted  
from Unicode to numbers using a trivial translation is meaningless  
due to various ordering schemes that are often locale-dependent.
>
> The origin of the problem Michael reported is down to the lack of a
> jdbc-type
> specification in the metadata, and the fact that JPOX's current
> "default" for
> char is to store it as INTEGER (for whatever reason) - hence why he  
> got
> the
> problem.

I'd say it is the lack of a default in the specification as opposed  
to the lack of a jdbc-type in the metadata. The usage for single  
character columns is often trivial: M/F for gender, A/B/C/D/E for  
answer, 0/1 for binary data where the database doesn't understand  
boolean, etc.

To summarize, I'd prefer that the default be whatever the JDO experts  
agree is the default, and we adapt the TCK to specify the jdbc-type  
in case the default turns out to be something other than CHAR.

Ok? I'll see you on the JDO expert alias. :-)

Craig
>
> Ok. I thought that you would agree that this is a bug in JPOX,  
> since the
> "obvious default" for a char column is CHAR.
>
>
> It is not that obvious when you have to support a wide range of
> databases and data types. The most obvious choice to me is the most
> common type among these databases.
>
>
>

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!


Mime
View raw message