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 20:07:42 GMT
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 <kwsutter@gmail.com> wrote:
> Patrick,
>
> On 8/23/07, Patrick Linskey <plinskey@gmail.com> 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 <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
> >
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message