Also would it not be hard to implement given it boundless nature. In reality is this not a char string and not an actual int.
- Phill -----Original Message----- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: August 23, 2007 1:17 PM To: [email protected] Subject: Re: BigInteger as @Id > 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
