db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Minutes: JDO TCK Conference Call Friday, Nov 2
Date Fri, 02 Nov 2007 22:10:55 GMT
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!


Mime
View raw message