db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Bengtson" <e...@jpox.org>
Subject RE: Enum handling
Date Sat, 03 Nov 2007 10:34:33 GMT
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)



Mime
View raw message