openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: BigInteger as @Id
Date Sun, 26 Aug 2007 05:43:04 GMT
Hi Kevin,

On Aug 24, 2007, at 5:30 AM, Kevin Sutter wrote:

> Craig,
>
> On 8/23/07, Craig L Russell <Craig.Russell@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!


Mime
View raw message