openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: BigInteger as @Id
Date Thu, 23 Aug 2007 21:09:53 GMT
Patrick,
On 8/23/07, Patrick Linskey <plinskey@gmail.com> wrote:
>
> I see where you're coming from.


Also, as I re-read section 2.1.4, there's this statement:  "Entities whose
primary keys use types other than these will not be portable."  This would
indicate that the specified types (ie. primitive, Date, etc) would be
portable, but there's nothing stopping you from using the other Basic types
(ie. BigInteger, BigDecimal, etc), if you so wish.  There doesn't seem to be
any CTS requirement on this usage, but the usage of these non-portable types
does seem like a valid request.  I'll open a JIRA Isssue: OPENJPA-331.

Thanks,
Kevin

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message