Another use case of enum persistence, is the persistence of arbitrary
values.=20

public enum Test {
RED(1), BLUE(5);
=20
private final int value;
=20
Test(int v)
{
this.value =3D v;
}
=20
public final int getValue()
{
return this.value;
}
=20
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/br...VAFIVEPLUGIN-51


-----Message d'origine-----
De=A0: Andy Jefferson [mailto:andy@jpox.org]=20
Envoy=E9=A0: samedi 3 novembre 2007 9:33
=C0=A0: jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet=A0: 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=20
default jdbc-type and that is used by the implementation so they have no
need=20
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=20
has VARCHAR as the default jdbc-type.

2. The only place where the section 18.4 default mappings are not used =
(e.g=20
FieldsOfCharacter), the TCK "orm" files add jdbc-type, and so don't =
impose
on=20
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=20
Oracle) are notoriously slow for obtaining basic schema information ... =
and=20
then we could refer to a JIRA I raised on Derby a year ago=20
http://issues.apache.org/jira/browse/DERBY-1996
For this reason, and for reasons of portability (not relying on the =
schema=20
being identical, but instead imposing the requirements in the mapping=20
information) JPOX has always relied on jdbc-type, whilst still providing =
a=20
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=20
still imply a String based persistence (to me). INTEGER would suggest=20
something else.



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

[ Post a follow-up to this message ]