Sorry, I was thinking of BigDecimal. Scratch that objection. -Patrick
On 8/23/07, Evan Ireland <[EMAIL PROTECTED]> wrote: > 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 > > > > -- Patrick Linskey 202 669 5907
