Hi, If the fix is checked into the 1.0.x branch already (check the svn commit data in the jira issue), then the 1.0.2 snapshot build should have the feature.
-Patrick On 11/25/07, klaasjan elzinga <[EMAIL PROTECTED]> wrote: > Judging from the jira comments you will have to wait for 1.0.2. The > issue is still open and is not yet marked as fixed. > > On Nov 25, 2007 1:15 PM, Miroslav Nachev <[EMAIL PROTECTED]> wrote: > > Yesterday (24.11.2007) I downloaded the last versions of OpenJPA: > > apache-openjpa-1.0.1-binary.zip > > apache-openjpa-1.1.0-SNAPSHOT-binary.zip > > > > Unfortunately I have the same problem. Can you tell men from where to > > download some version where this is solved? > > > > Now I am trying to compile OpenJPA SVN version with NetBeans 6.x but I > have > > compile errors. > > > > Any suggestions? > > > > > > Miro. > > > > > > On 11/25/07, klaasjan elzinga <[EMAIL PROTECTED]> wrote: > > > > > > PLz see > > > > http://mail-archives.apache.org/mod_mbox/openjpa-users/200707.mbox/[EMAIL > PROTECTED] > > > > > > [OPENJPA-331] - Allow BigInteger and other Basic types as Primary Keys > > > https://issues.apache.org/jira/browse/OPENJPA-331 > > > (This issue seems to resolve your problem, Jira states its fixed in > > > 1.0.2 and 1.1.0., but its also in the release notes of 1.0.1) > > > > > > Perhaps its an idea to map the id as a string in the class? See the > > > manual for the property StoreLargeNumbersAsStrings: > > > StoreLargeNumbersAsStrings: Many databases have limitations on the > > > number of digits that can be stored in a numeric field (for example, > > > Oracle can only store 38 digits). For applications that operate on > > > very large BigInteger and BigDecimal values, it may be necessary to > > > store these objects as string fields rather than the database's > > > numeric type. Note that this may prevent meaningful numeric queries > > > from being executed against the database. Defaults to false. > > > > > > > > > On Nov 24, 2007 4:49 PM, Miroslav Nachev <[EMAIL PROTECTED]> wrote: > > > > TopLink works with BigInteger and BigDecimal data types. > > > > It is not possible to use Long or Integer instead BigInteger because > the > > > > precision of Integer is 10, the precision of Long is 20 and the > > > precision of > > > > BigInteger is not limited. Most of the databases are limited the > > > precision > > > > up to 38 but in some like PostgreSQL is possible up to 8000 or no > limit > > > for > > > > the last version. > > > > > > > > So, how can I use Long with max precision of 20 digits where in the > > > database > > > > is declared DECIMAL(36,0)? > > > > > > > > > > > > Miro. > > > > > > > > > > > > On 11/24/07, klaasjan elzinga <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Is it an option to declare the id as a Long/Integer field ie of the > > > > > BigInteger? I think that will be the solution. And I don't think it > is > > > > > a restriction, it is just not supported. > > > > > > > > > > KlaasJan > > > > > > > > > > On Nov 24, 2007 3:21 PM, Miroslav Nachev <[EMAIL PROTECTED]> > wrote: > > > > > > Hi, > > > > > > > > > > > > Can I use BigInteger /DECIMAL(P,0)/ and BigDecimal as PrimaryKey ? > > > This > > > > > is > > > > > > possible in any Database but OpenJPA throws an error: > > > > > > Exception in thread "main" <openjpa-1.1.0-SNAPSHOT-r420667:592964M > > > fatal > > > > > > user error> org.apache.openjpa.persistence.ArgumentException: Type > > > > > "class > > > > > > test.DataObject" declares field "objectId" as a primary key, but > > > keys of > > > > > > type "java.math.BigInteger" are not supported. > > > > > > > > > > > > Why is that restriction? > > > > > > > > > > > > > > > > > > Regards, > > > > > > Miro. > > > > > > > > > > > > > > > > > > > > > -- Patrick Linskey 202 669 5907
