| Hi Dan, On Jul 22, 2005, at 1:04 AM, Daniel John Debrunner wrote:
The intent of the separate jdbc-type and sql-type is to give the user the most flexibility in defining the known constraints of the data in the object model mapped to the constraints of the database. For example, in the JDO TCK, we test the ability of an implementation to store the range of valid char values, which for some fields is 0..65535. We know many databases that don't allow this range to be stored as a CHAR(1) even though Derby does. So we specify this as a jdbc-type INTEGER. Other char fields are known to store a smaller range of values, and we know that the values can be stored in any database as a single byte using any encoding that maps ASCII to one byte. For these columns, we use jdbc-type of CHAR and expect to be able to store these limited values there. If we only had to deal with the object model view of the data, it would be easier to define the type mapping. But real world databases come with their own set of applications already written that define the content, and the object model needs to conform to that content. So it's inappropriate to always map char to INTEGER, even though we know that it would always work for the object model. But other applications might have defined the column's data in a different way. Craig
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! |
smime.p7s
Description: S/MIME cryptographic signature
