> > Well in the case of a char it is, but in the case of a java double for
> > example ? It all depends on the RDBMS. Some RDBMS support DOUBLE, some
> > DECIMAL, some NUMERIC, some have other types ...
>
> This is the jdbc-type ("generic sql type"), not the sql-type we're
> talking about (there is a separate sql-type that the user can specify
> if they want to get database specific).
>
> The idea is that the user could override the jdbc-type if necessary,
> and the jdo impl would use jdbc-type plus length plus nullability to
> map to a natural sql-type that is database specific.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). We've always encouraged our users to specify the jdbc-type if they want things to be JDO-impl independent for this very reason. While a default may make sense so people know what they get if nothing is specified, there are *a lot* of situations where the JDBC driver doesnt support a "generic" sql type even -- Andy Java Persistent Objects - JPOX
