Patrick, On 8/23/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > 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?
The very first sentence of this section: > 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: The key words is "should be". Elsewhere in this section, it implies that Id's can be any basic type: "A simple (i.e., non-composite) primary key must correspond to a single persistent field or property of the entity class." Thus, BigInteger would be an allowable type based on section 2.1.6: "If the type of the field or property is one of the following, it is mapped in the same way as it would if it were annotated as Basic: Java primitive types, wrappers of the primitive types, java.lang.String, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, byte[], Byte[], char[], Character[], enums, any other type that implements Serializable. See Sections 9.1.18 through 9.1.21." I also learned that Glassfish allows the use of BigInteger, if you care what the RI does... Kevin 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 >
