I think BigInteger should be supported by OpenJPA as a pk for an Entity. If your requirements go beyond the domain of Long, what do you do then?

I'd like to see it standardized as a portable requirement for the next JPA specification.

Craig

On Aug 23, 2007, at 7:56 AM, Kevin Sutter 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

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to