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 ? 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. 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. -- Andy
