> any Java primitive type; any primitive wrapper type; java.lang.String; > java.util.Date; > java.sql.Date.
BigInteger is not among these types. What part of the spec indicates that BigInteger should be included in the list? I interpreted the approximate-number bit to be a caution to users to avoid using float and double field types. -Patrick On 8/23/07, Kevin Sutter <[EMAIL PROTECTED]> 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. It > says "should be"... > > Section 2.1.4: A simple (i.e., non-composite) primary key must correspond > to a single persistent field or property of > the 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) should > never be used in primary keys. Entities whose primary keys use types other > than these will not be portable. > If generated primary keys are used, only integral types will be portable. If > java.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 of > the @Basic types? Thoughts? > > Thanks, > Kevin > -- Patrick Linskey 202 669 5907
