db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Enum handling
Date Sat, 03 Nov 2007 20:23:17 GMT

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

Good idea. I'll make this change.
> 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?

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

Yes, and that's what we thought. But I'm persuaded by your arguments  
and will make the spec changes. Here's a preview:

<proposed> 15.1
Mapping enums
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message