Patrick, In what sense does BigInteger have a lack of precision?
> -----Original Message----- > From: Patrick Linskey [mailto:[EMAIL PROTECTED] > Sent: Friday, 24 August 2007 8:08 a.m. > To: [email protected] > Subject: Re: BigInteger as @Id > > 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 >
