Hi Craig, Michelle, > Makes sense to me, but the spec lead thinks the implementation should > check the actual type in the database.
Well while I understand what our spec lead says I also point out :- 1. All TCK tests so far use the table in 18.4 in the spec to define the default jdbc-type and that is used by the implementation so they have no need to go to the datastore to validate the tables and hence define how they will be mapped. There presumably will be an entry for java.lang.Enum added that has VARCHAR as the default jdbc-type. 2. The only place where the section 18.4 default mappings are not used (e.g FieldsOfCharacter), the TCK "orm" files add jdbc-type, and so don't impose on the implementation the overhead of having to go to the datastore to get this information there either. 3. The spec lead has more faith than me in JDBC drivers ;-), and some (e.g Oracle) are notoriously slow for obtaining basic schema information ... and then we could refer to a JIRA I raised on Derby a year ago http://issues.apache.org/jira/browse/DERBY-1996 For this reason, and for reasons of portability (not relying on the schema being identical, but instead imposing the requirements in the mapping information) JPOX has always relied on jdbc-type, whilst still providing a means of validating this mapping definition against the underlying datastore (if the user wishes to do so). Does the spec prohibit this mode of operation? 4. The schema for the FieldsOfEnum has two types of columns ... VARCHAR(256) and CHAR(2). Even if JPOX went to the datastore and found CHAR(2), that would still imply a String based persistence (to me). INTEGER would suggest something else. -- Andy (Java Persistent Objects - http://www.jpox.org)
