Hi Andy,On Jul 20, 2005, at 9:57 AM, Andy Jefferson wrote: 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).
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?
We've always encouraged our users to specify the jdbc-type if they want things to be JDO-impl independent for this very reason.
Right, so your users just want to specify the database specific type because they know what kind of database they are using.
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
Where does this give you trouble?
Thanks,
Craig
-- Andy Java Persistent Objects - JPOX
|
smime.p7s
Description: S/MIME cryptographic signature
