I'd like to see it standardized as a portable requirement for the next JPA specification.
Craig On Aug 23, 2007, at 7:56 AM, Kevin Sutter wrote:
Hi,Shouldn't BigInteger fields be allowed to be primary keys? According to section 2.1.4, the requirements on the @Id field are not real specific. Itsays "should be"...Section 2.1.4: A simple (i.e., non-composite) primary key must correspondto a single persistent field or property ofthe entity class. The Id annotation is used to denote a simple primary key.See section 9.1.8. Also from Section 2.1.4: The primary key (or field or property of a composite primary key) should be one of the following types: any Java primitive type; any primitive wrapper type; java.lang.String; java.util.Date; java.sql.Date. In general, however, approximate numeric types (e.g., floating point types) shouldnever be used in primary keys. Entities whose primary keys use types otherthan these will not be portable.If generated primary keys are used, only integral types will be portable. Ifjava.util.Date is used as a primary key field or property, the temporal type should be specified as DATE. When I just attempted it, I got the following error: <openjpa-1.0.0-SNAPSHOT-r420667:568164 fatal user error> org.apache.openjpa.util.MetaDataException: Type "class org.apache.openjpa.persistence.simple.AllFieldTypes" declares field"bigIntegerField" as a primary key, but keys of type "java.math.BigInteger"are not supported.Any reason for this limitation? Looking at the ClassMetaData class, it looks like we are reading "should be" as "must be". Should we allow any ofthe @Basic types? Thoughts? Thanks, Kevin
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
