db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject Re: Enum handling
Date Sat, 03 Nov 2007 08:33:05 GMT
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 
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)

View raw message