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:31:51 GMT
Hi Erik,

This example should fit in with what Matthew is doing for more  
flexible mapping of enums to fixed precision types.

Craig

On Nov 3, 2007, at 3:34 AM, Erik Bengtson wrote:

> Another use case of enum persistence, is the persistence of arbitrary
> values.
>
> public enum Test {
>     RED(1), BLUE(5);
>
>     private final int value;
>
>     Test(int v)
>     {
>         this.value = v;
>     }
>
>     public final int getValue()
>     {
>         return this.value;
>     }
>
>     public final static Enum getEnum(int i)
>     {
>         switch(i)
>         {
>             case 1: return Test.RED;
>             case 5: return Test.BLUE;
>         }
>         return null;
>     }
> }
>
>
> Refer to:
> http://www.jpox.org/servlet/jira/browse/JAVAFIVEPLUGIN-51
>
>
> -----Message d'origine-----
> De : Andy Jefferson [mailto:andy@jpox.org]
> Envoyé : samedi 3 novembre 2007 9:33
> À : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
> Objet : Re: Enum handling
>
> 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)
>
>

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!


Mime
View raw message