openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: BigInteger as @Id
Date Thu, 23 Aug 2007 17:16:41 GMT
> 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 <kwsutter@gmail.com> 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

Mime
View raw message