You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@jpox.org> on 2007/11/03 09:33:05 UTC
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)
Re: Enum handling
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
RE: Enum handling
Posted by Erik Bengtson <er...@jpox.org>.
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)
Re: Enum handling
Posted by Craig L Russell <Cr...@Sun.COM>.
On Nov 3, 2007, at 1:33 AM, Andy Jefferson wrote:
> 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.
Good idea. I'll make this change.
>
> 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?
No, and for portability, I think we need some way to specify the
default so schema generation is possible, and additionally provide
for the user to explicitly tell the implementation what type to
expect from the database.
>
> 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.
Yes, and that's what we thought. But I'm persuaded by your arguments
and will make the spec changes. Here's a preview:
<proposed> 15.1
Mapping enums
Mapping an enum to a fixed-precision numeric type uses the ordinal()
value for storage; mapping to a character column type (CHAR, VARCHAR,
etc.) uses the name() value for storage; mapping to any other column
type is not portable.
The default jdbc-type for columns mapped to enums is VARCHAR. This
provides maximum flexibility as the enum evolves, as it uses the name
of the enum for storage. As more enum values are added, the name does
not change, whereas the ordinal value will change if enum values are
added anywhere except at the end.
For portability, if the mapping should use the ordinal value for
storage, then the jdbc-type must be specified in the column metadata
as a fixed precision numeric type. An implementation might support
floating point types for storage, and might auto-detect the column
type but this behavior is not portable.
</proposed>
The tck will need to update the orm files for the enum fields to
specify the jdbc-type for the numeric columns.
Craig
>
>
>
> --
> 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!