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 (JIRA)" <ji...@apache.org> on 2007/08/23 23:08:30 UTC
[jira] Created: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
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
Reporter: Kevin Sutter
Assignee: Kevin Sutter
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.
Re: [jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic types as Primary Keys
Posted by Patrick Linskey <pl...@gmail.com>.
Hi,
> 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?
The only real changes I made to the contents of the patch were to the
whitespace treatment around method braces and if statements.
Did you find the license header in the OpenJPA instructions? If so,
can you post a URL to it? We should update it. If you could attach a
patch based on current trunk that changes the license headers to look
like the headers in other files, that'd be great. (I'd change it
myself, but I'm not really sure if I'm supposed to do that or not.)
> Tomorrow I can do similar patch for 1.0.2. Is it OK for you?
Actually, it's not the patching that's the issue -- I can generate a
patch with 'svn diff' easily. But this machine has a lame version of
'patch' on it that doesn't understand unified format (I've been using
IntelliJ to apply patches to trunk). I'm sure I could install a good
patch impl or something, but since we don't have a 1.0.2 release
schedule right now, it doesn't seem worth the effort.
> Also tomorrow I can create snapshot. What do you think about that?
Thanks for offering, but it's a bit of a pain to do. In fact, you
probably couldn't do it in one day, since you'd need to get access to
the CTS; we run the CTS before all our snapshot uploads. There are a
few people out there who are set up to do this already, but again,
unless there's a reason to get a new snapshot up before the 26th, the
easiest approach is probably just to wait so I can reboot the machine
once I get physical access to it. Do you have any urgency on getting a
snapshot vs. just using a patch jar or a special build?
-Patrick
On Dec 17, 2007 12:33 AM, Miroslav Nachev <mi...@space-comm.com> wrote:
> 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) <ji...@apache.org> 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.
> >
> >
>
--
Patrick Linskey
202 669 5907
Re: [jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic types as Primary Keys
Posted by Miroslav Nachev <mi...@space-comm.com>.
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) <ji...@apache.org> 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.
>
>
[jira] Updated: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Miroslav Nachev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Miroslav Nachev updated OPENJPA-331:
------------------------------------
Attachment: license-fix-OpenJPA-331-v110.patch
Is that OK?
I am so sorry but I am not so friendly with License matter. If this is not OK, please fix it or exact tell me what to do.
> 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, license-fix-OpenJPA-331-v110.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.
[jira] Resolved: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey resolved OPENJPA-331.
-------------------------------------
Resolution: Fixed
Merged to 1.0.x line.
> 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, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.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.
[jira] Updated: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Miroslav Nachev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Miroslav Nachev updated OPENJPA-331:
------------------------------------
Attachment: license-fix-OpenJPA-331-v110.patch
Is that OK?
I am so sorry but I am not so friendly with License matter. If this is not OK, please fix it or exact tell me what to do.
> 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, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.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.
[jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553481 ]
Craig Russell commented on OPENJPA-331:
---------------------------------------
Hi Miro,
Thanks, this is very close to what we need.
The license header is ok, but the copyright needs to be removed from the individual files and put into the openjpa-project/NOTICE.txt file. Something like this:
* OpenJPA includes the following software copyright 2007 Miroslav Nachev
openjpa-kernel/src/main/java/org/apache/openjpa/util/BigDecimalId.java
openjpa-kernel/src/main/java/org/apache/openjpa/util/BigIntegerId.java
openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/identity/SQLBigIntegerIdEntity.java
openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/identity/SQLBigDecimalIdEntity.java
openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/identity/TestSQLBigIntegerId.java
openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/identity/TestSQLBigDecimalId.java
Thanks,
Craig
> 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, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.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.
[jira] Updated: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Miroslav Nachev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Miroslav Nachev updated OPENJPA-331:
------------------------------------
Attachment: license-fix-OpenJPA-331-v110.patch
I hope that now everything is OK.
> 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, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.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.
[jira] Updated: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Albert Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Albert Lee updated OPENJPA-331:
-------------------------------
Fix Version/s: (was: 1.0.1)
1.0.2
Defer to next release.
> 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
>
>
> 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.
[jira] Updated: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Sutter updated OPENJPA-331:
---------------------------------
Fix Version/s: 1.1.0
1.0.1
Affects Version/s: 1.0.0
> 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.1, 1.1.0
>
>
> 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.
[jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554961 ]
Craig Russell commented on OPENJPA-331:
---------------------------------------
I've checked in the updated license information into trunk.
I'll leave the issue open in case someone wants to apply the patch to the branch. I've got some ^M line ending issues when applying the patch to the branch.
> 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, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.patch, license-fix-OpenJPA-331-v110.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.
[jira] Updated: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Miroslav Nachev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Miroslav Nachev updated OPENJPA-331:
------------------------------------
Attachment: fix-OpenJPA-331.patch
> 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.
[jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552194 ]
Patrick Linskey commented on OPENJPA-331:
-----------------------------------------
Resolved in trunk; keeping open since this probably deserves to be in 1.0.2, but I cannot apply patches to 1.0.2 on this machine due to a lame patch implementation.
The new files have a slightly different ASL license banner at the top. To the best of my non-legally-schooled knowledge, it looks right, and I'm reluctant to change someone else's license banner, but it seemed worth highlighting.
> 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.
[jira] Commented: (OPENJPA-331) Allow BigInteger and other Basic
types as Primary Keys
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552836 ]
Craig Russell commented on OPENJPA-331:
---------------------------------------
Hi Miro,
Thanks for the patch! The copyright and license in the headers of the new files are an issue that I'd like you to fix and resubmit. Since the changes have already been checked in, an update to the headers and/or NOTICE.txt is all that's needed.
Please see http://cwiki.apache.org/confluence/display/openjpa/Found+a+Bug for details on the headers that are needed.
Thanks,
Craig
> 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.