I see where you're coming from. Personally, I think that using a BigInteger for a pk is a bad idea, due to the lack of precision. I therefore would not invest any time in adding the ability to use them.
-Patrick On 8/23/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > 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 > > > -- Patrick Linskey 202 669 5907
