Re: Enum handling

[Craig L Russell]

Hi Erik,




Craig

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

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

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:[EMAIL PROTECTED]
Envoyé : samedi 3 novembre 2007 9:33
À : jdo-dev@db.apache.org; [EMAIL PROTECTED]
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 :-


need



has VARCHAR as the default jdbc-type.


on


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


(if the user wishes to do so). Does the spec prohibit this mode of
operation?




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



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

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

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