You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/08/23 16:56:28 UTC
BigInteger as @Id
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
Re: BigInteger as @Id
Posted by Kevin Sutter <kw...@gmail.com>.
Patrick,
On 8/23/07, Patrick Linskey <pl...@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 <kw...@gmail.com> wrote:
> > Patrick,
> >
> > On 8/23/07, Patrick Linskey <pl...@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 <kw...@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
>
Re: BigInteger as @Id
Posted by Patrick Linskey <pl...@gmail.com>.
Sorry, I was thinking of BigDecimal. Scratch that objection.
-Patrick
On 8/23/07, Evan Ireland <ei...@sybase.com> wrote:
> 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 <kw...@gmail.com> wrote:
> > > Patrick,
> > >
> > > On 8/23/07, Patrick Linskey <pl...@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 <kw...@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
> >
>
>
--
Patrick Linskey
202 669 5907
RE: BigInteger as @Id
Posted by Evan Ireland <ei...@sybase.com>.
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 <kw...@gmail.com> wrote:
> > Patrick,
> >
> > On 8/23/07, Patrick Linskey <pl...@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 <kw...@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
>
Re: BigInteger as @Id
Posted by Patrick Linskey <pl...@gmail.com>.
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 <kw...@gmail.com> wrote:
> Patrick,
>
> On 8/23/07, Patrick Linskey <pl...@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 <kw...@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
Re: BigInteger as @Id
Posted by Kevin Sutter <kw...@gmail.com>.
Patrick,
On 8/23/07, Patrick Linskey <pl...@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 <kw...@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
>
RE: BigInteger as @Id
Posted by Phill Moran <pj...@rogers.com>.
Also would it not be hard to implement given it boundless nature. In reality is
this not a char string and not an actual int.
- Phill
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: August 23, 2007 1:17 PM
To: dev@openjpa.apache.org
Subject: Re: BigInteger as @Id
> 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 <kw...@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
Re: BigInteger as @Id
Posted by Patrick Linskey <pl...@gmail.com>.
> 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 <kw...@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
Re: BigInteger as @Id
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
On Aug 24, 2007, at 5:30 AM, Kevin Sutter wrote:
> Craig,
>
> On 8/23/07, Craig L Russell <Cr...@sun.com> wrote:
>>
>> 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?
>
>
> Not exactly sure I understand what you mean by going "beyond the
> domain of
> Long". You mean what if the BigInteger value goes beyond the max
> value for
> a Long? Or, are you speaking in a more general context and not just
> BigInteger values?
I meant what do you do if you want a numeric primary key and the key
values are larger than fit into a Long. You can use a String but it
might be more natural to use a BigInteger.
>
> I'd like to see it standardized as a portable requirement for the
>> next JPA specification.
>
>
> Agree.
Cool. Let's make it happen.
Craig
>
> Kevin
>
> 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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: BigInteger as @Id
Posted by Kevin Sutter <kw...@gmail.com>.
Craig,
On 8/23/07, Craig L Russell <Cr...@sun.com> wrote:
>
> 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?
Not exactly sure I understand what you mean by going "beyond the domain of
Long". You mean what if the BigInteger value goes beyond the max value for
a Long? Or, are you speaking in a more general context and not just
BigInteger values?
I'd like to see it standardized as a portable requirement for the
> next JPA specification.
Agree.
Kevin
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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
Re: BigInteger as @Id
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!