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 Wed, 20 Jul 2005 22:25:53 GMT
Hi Andy,

On Jul 20, 2005, at 10:24 AM, Andy Jefferson wrote:

> Hi Craig,
>>> I'm also talking about the jdbc-type (or to be specific
>>> javax.sql.Types). So
>>> the JDO impl should always take JDBC Types.DOUBLE when the user has
>>> a Java
>>> double field? Many JDBC drivers *don't* provide a type mapping for
>>> Types.DOUBLE (many don't provide support for several of the
>>> "standard" JDBC
>>> types).
>> I'm trying to see where the confusion is. The attribute is only
>> specified if the user wants to override the default for the field
>> type. Is this what you're talking about?
> Just trying to understand what you're proposing with respect to how  
> JDO impls
> decide a "default" RDBMS type. You previously said that your intent  
> of the
> spec was that the jdbc-type (when not specified) should be the  
> "obvious one
> for the java type". I was simply pointing out that if the user has  
> a Java
> double, then the obvious jdbc-type would be "DOUBLE", and that many  
> dont map that in their JDBC drivers, so what use is that default ?

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.

But regardless of what was used for schema creation, I expected that  
when binding values to a prepared statement, the jdo impl would use  
the setDouble method, and when retrieving values from a result set,  
it would use getDouble. Similarly, unless the user had explicitly  
said to use jdbc-type INTEGER, I'd expect the jdo impl to use  
setString and getString for char fields.

I had not expected that the jdbc-type would be used for deciding how  
to perform parameter or result set bindings. But I can see how you  
could implement JPOX using the jdbc-type as a clue.
> 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.

Ok. I thought that you would agree that this is a bug in JPOX, since  
the "obvious default" for a char column is CHAR.
> We know JPOX's internal type mapping needs more flexibility, but  
> the JDO spec
> doesn't define what we have to do currently, so our assumption til  
> now was
> that the user can define their required type if they have one in mind,
> otherwise they take what we give them.

It wasn't clear to me that the issue was flexibility, just changing  
the way you bind to result set and prepared statements for char types.

> -- 
> Andy

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