openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Ireland" <eirel...@sybase.com>
Subject RE: BigInteger as @Id
Date Thu, 23 Aug 2007 20:32:12 GMT
Patrick,

In what sense does BigInteger have a lack of precision? 

> -----Original Message-----
> From: Patrick Linskey [mailto:plinskey@gmail.com] 
> Sent: Friday, 24 August 2007 8:08 a.m.
> To: dev@openjpa.apache.org
> 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 <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