Re: Enum handling

[Craig L Russell]

On Nov 3, 2007, at 1:33 AM, Andy Jefferson wrote:

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 :-


has VARCHAR as the default jdbc-type.

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

Good idea. I'll make this change.

information there either.


then we could refer to a JIRA I raised on Derby a year ago
http://issues.apache.org/jira/browse/DERBY-1996

being identical, but instead imposing the requirements in the mapping

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 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 For this reason, and for reasons of portability (not relying on the schema 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?

No, and for portability, I think we need some way to specify the default so schema generation is possible, and additionally provide for the user to explicitly tell the implementation what type to expect from the database.

still imply a String based persistence (to me). INTEGER would suggest
something else.

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

<proposed> 15.1
Mapping enums

</proposed>



Craig

Yes, and that's what we thought. But I'm persuaded by your arguments and will make the spec changes. Here's a preview: Mapping an enum to a fixed-precision numeric type uses the ordinal() value for storage; mapping to a character column type (CHAR, VARCHAR, etc.) uses the name() value for storage; mapping to any other column type is not portable. The default jdbc-type for columns mapped to enums is VARCHAR. This provides maximum flexibility as the enum evolves, as it uses the name of the enum for storage. As more enum values are added, the name does not change, whereas the ordinal value will change if enum values are added anywhere except at the end. For portability, if the mapping should use the ordinal value for storage, then the jdbc-type must be specified in the column metadata as a fixed precision numeric type. An implementation might support floating point types for storage, and might auto-detect the column type but this behavior is not portable. The tck will need to update the orm files for the enum fields to specify the jdbc-type for the numeric columns.

--
Andy  (Java Persistent Objects - http://www.jpox.org)

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