Hi Patrick, The patch is created following the instructions on the OpenJPA web. Can you tell me how to do future patches which to be not lamed? Tomorrow I can do similar patch for 1.0.2. Is it OK for you? Also tomorrow I can create snapshot. What do you think about that?
Regards, Miro. On 12/16/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote: > > > [ > https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552195] > > Patrick Linskey commented on OPENJPA-331: > ----------------------------------------- > > Oh, and thanks for the patch, Miro! > > One more note: it looks like the automated build machine is currently > offline, so this won't make it into a snapshot until it comes back online or > someone manually creates a snapshot. I will not be able to debug the offline > machine until late next week. > > > Allow BigInteger and other Basic types as Primary Keys > > ------------------------------------------------------ > > > > Key: OPENJPA-331 > > URL: https://issues.apache.org/jira/browse/OPENJPA-331 > > Project: OpenJPA > > Issue Type: Bug > > Components: kernel > > Affects Versions: 0.9.7, 1.0.0 > > Reporter: Kevin Sutter > > Assignee: Kevin Sutter > > Fix For: 1.0.2, 1.1.0 > > > > Attachments: fix-OpenJPA-331.patch > > > > > > Section 2.1.4 of the JPA spec outlines the requirements for a primary > key (@Id): > > 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. > > Right now, we are treating the "should be" statement above as "must be" > and only allowing the specified types as primary keys. But, the sentence in > the middle of this paragraph ("Entities whose primary keys use types other > than these will not be portable.") indicates that other types can also be > allowed, but may not be portable. > > It seems that Glassfish allows these additional Basic types as primary > keys. We should probably allow the same thing to keep up with the Jones'. > > This was discussed on dev mailing list. > http://www.nabble.com/BigInteger-as-%40Id-tf4318071.html > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
