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 RDBMS
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.
smime.p7s