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/02 20:19:22 UTC
Re: Minutes: JDO TCK Conference Call Friday, Nov 2
> 1. Enum tests: Michelle is just about ready to check in. Running last
> tests. In JPOX, enums are not persistent by default and seem to have
> trouble with numeric types. AI Michelle check in tests; AI Craig
> update spec to mandate enums as singleton, immutable objects and
> allow other enum support;
So are enum fields going to be default "persistent" now ?
Await to see what tests we are talking about here ... persistence?,
retrieval?, JDOQL?, something else, because we obviously have some of our own
and test the majority of things. The only known issue is for JDOQL
expressions comparing an enum field with the enum value (when it was
persisted as a numeric). Comparing with the enum ordinal works fine in that
situation.
> Email discussion: Proposed method to ask the persistence manager for
> managed instances might have a signature Object[ ] getManagedInstances
> (ObjectState[ ], Class... classes) which filters instances based on
> their state and class. This could be part of 2.1 or deferred to 2.2.
> Is this something that JPOX wants to see sooner?
JPOX already has
Collection PM.getManagedObjects()
and could have any of the mentioned combinations pretty fast ;-)
--
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!
Re: Enum handling
Posted by Andy Jefferson <an...@jpox.org>.
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: Minutes: JDO TCK Conference Call Friday, Nov 2
Posted by Craig L Russell <Cr...@Sun.COM>.
Here's the working copy of the spec updates:
<spec update>
6.4.3
Enums
JDO implementations that support Java 5 must support fields of enum
types and collections of as enum types identified above and
optionally arrays of enum types. If arrays are supported, arrays of
enums must be supported.
Portable JDO applications must not depend on whether these fields are
treated as SCOs or FCOs.
6.4.5
Complex enum types
Complex enum types are enums that contain fields that might change
during execution instead of being initialized during class
initialization. While it is possible to manage these singleton
instances persistent state, there are issues with the transaction
isolation of the instances and with the ownership of the instances by
a persistence manager. Therefore, dynamically changing fields of enum
types are not persistent.
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 an error.
</spec update>
The idea I had was that the jdo implementation would be aware of the
column type being mapped to, but if this is not practical we'll need
to come up with something else...
Craig
On Nov 2, 2007, at 1:04 PM, Michelle Caisse wrote:
> Andy Jefferson wrote:
>
>>> test(org.apache.jdo.tck.models.fieldtypes.TestFieldsOfSimpleEnum)
>>> javax.jdo.
>>> JDODataStoreException: Cannot set String parameter: value = AL
>>> for column
>>> "applicationidentity1.FIELDSOFENUMORDINAL.ENUM94" : Invalid
>>> character
>>> string format for type INTEGER.
>>>
>>> I know this is supposed to work, so maybe you can tell us what's
>>> going
>>> wrong.
>>>
>>
>> Hi Michelle,
>>
>> How are you expecting jPOX to know you want to persist as an
>> numeric rather than String ? JPOX support is based on how we
>> thought it should be implemented (since not defined in the JDO
>> spec explicitly). We rely on "jdbc-type" currently, with default
>> being String-based.
>>
>>
>>
> Makes sense to me, but the spec lead thinks the implementation
> should check the actual type in the database.
>
> -- Michelle
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: Minutes: JDO TCK Conference Call Friday, Nov 2
Posted by Michelle Caisse <Mi...@Sun.COM>.
Andy Jefferson wrote:
>>test(org.apache.jdo.tck.models.fieldtypes.TestFieldsOfSimpleEnum)javax.jdo.
>>JDODataStoreException: Cannot set String parameter: value = AL for column
>>"applicationidentity1.FIELDSOFENUMORDINAL.ENUM94" : Invalid character
>>string format for type INTEGER.
>>
>>I know this is supposed to work, so maybe you can tell us what's going
>>wrong.
>>
>>
>
>Hi Michelle,
>
>How are you expecting jPOX to know you want to persist as an numeric rather
>than String ? JPOX support is based on how we thought it should be
>implemented (since not defined in the JDO spec explicitly). We rely
>on "jdbc-type" currently, with default being String-based.
>
>
>
>
Makes sense to me, but the spec lead thinks the implementation should
check the actual type in the database.
-- Michelle
Re: Minutes: JDO TCK Conference Call Friday, Nov 2
Posted by Andy Jefferson <an...@jpox.org>.
> test(org.apache.jdo.tck.models.fieldtypes.TestFieldsOfSimpleEnum)javax.jdo.
>JDODataStoreException: Cannot set String parameter: value = AL for column
> "applicationidentity1.FIELDSOFENUMORDINAL.ENUM94" : Invalid character
> string format for type INTEGER.
>
> I know this is supposed to work, so maybe you can tell us what's going
> wrong.
Hi Michelle,
How are you expecting jPOX to know you want to persist as an numeric rather
than String ? JPOX support is based on how we thought it should be
implemented (since not defined in the JDO spec explicitly). We rely
on "jdbc-type" currently, with default being String-based.
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: Minutes: JDO TCK Conference Call Friday, Nov 2
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Andy,
On Nov 2, 2007, at 12:19 PM, Andy Jefferson wrote:
>> 1. Enum tests: Michelle is just about ready to check in. Running last
>> tests. In JPOX, enums are not persistent by default and seem to have
>> trouble with numeric types. AI Michelle check in tests; AI Craig
>> update spec to mandate enums as singleton, immutable objects and
>> allow other enum support;
>
> So are enum fields going to be default "persistent" now ?
I think it makes sense. Just like other immutable object types like
Integer.
I'm open to having them default non-persistent but seems better to
have them default persistent.
> Await to see what tests we are talking about here ... persistence?,
> retrieval?, JDOQL?, something else, because we obviously have some
> of our own
> and test the majority of things.
For starters, just store/retrieve enum values. Take a look at the
tests that Michelle checked in and see if they're ok.
> The only known issue is for JDOQL
> expressions comparing an enum field with the enum value (when it was
> persisted as a numeric). Comparing with the enum ordinal works fine
> in that
> situation.
We haven't discussed adding JDOQL tests. Maybe you could suggest
some, or contribute some.
>
>> Email discussion: Proposed method to ask the persistence manager for
>> managed instances might have a signature Object[ ]
>> getManagedInstances
>> (ObjectState[ ], Class... classes) which filters instances based on
>> their state and class. This could be part of 2.1 or deferred to 2.2.
>> Is this something that JPOX wants to see sooner?
>
> JPOX already has
> Collection PM.getManagedObjects()
> and could have any of the mentioned combinations pretty fast ;-)
Cool. If you could comment further on the specific API we might get
consensus pretty fast. A couple of things we need to discuss: the
return type of Object[ ] vs. Collection; argument type for
ObjectState and Class of Collection<ObjectState> vs ObjectState[ ];
order of parameters if we use ObjectState[ ] because only one can be
varargs.
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!
Re: Minutes: JDO TCK Conference Call Friday, Nov 2
Posted by Michelle Caisse <Mi...@Sun.COM>.
Andy Jefferson wrote:
>>1. Enum tests: Michelle is just about ready to check in. Running last
>>tests. In JPOX, enums are not persistent by default and seem to have
>>trouble with numeric types. AI Michelle check in tests; AI Craig
>>update spec to mandate enums as singleton, immutable objects and
>>allow other enum support;
>>
>>
>
>So are enum fields going to be default "persistent" now ?
>Await to see what tests we are talking about here ... persistence?,
>retrieval?, JDOQL?, something else, because we obviously have some of our own
>and test the majority of things. The only known issue is for JDOQL
>expressions comparing an enum field with the enum value (when it was
>persisted as a numeric). Comparing with the enum ordinal works fine in that
>situation.
>
>
Tests were just checked in. Try, for example, models1.conf, where we get:
test(org.apache.jdo.tck.models.fieldtypes.TestFieldsOfSimpleEnum)javax.jdo.JDODataStoreException:
Cannot set String parameter: value = AL for column
"applicationidentity1.FIELDSOFENUMORDINAL.ENUM94" : Invalid character
string format for type INTEGER.
I know this is supposed to work, so maybe you can tell us what's going
wrong.
Other issues: enums not persistent by default in jpox, as you know, and
arrays of enums not supported.
-- Michelle
>
>
>>Email discussion: Proposed method to ask the persistence manager for
>>managed instances might have a signature Object[ ] getManagedInstances
>>(ObjectState[ ], Class... classes) which filters instances based on
>>their state and class. This could be part of 2.1 or deferred to 2.2.
>>Is this something that JPOX wants to see sooner?
>>
>>
>
>JPOX already has
>Collection PM.getManagedObjects()
>and could have any of the mentioned combinations pretty fast ;-)
>
>
>