The OpenJPA board report for August was updated and will be submitted
to the board tomorrow (Friday). If you have any updates, please
either edit and commit the changes to trunk/board/2007-08.txt or send
email to the dev alias and I'll do the edit.
Thanks,
Craig
Craig Russell
Architect, S
OpenJPA Developers-
A fourth attempt is now being made to cut the 1.0.0 release after the
discussion at http://www.nabble.com/-VOTE--Approve-OpenJPA-1.0.0-
release-%282nd-attempt%29-tf4309295.html .
A candidate build for OpenJPA 1.0.0 is available at:
http://openjpa.apache.org/builds/1.0.
Online report :
http://vmbuild1.apache.org/continuum/buildResult.action?buildId=2306&projectId=32
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 23 Aug 2007 16:35:22 -0700
Finished at: Thu 23 Aug 2007 16:46:20 -0700
Total time: 10m 58s
Build Trigger: Schedule
Build
At Kevin's request, I'm rescinding this vote.
-Patrick
On 8/22/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> OpenJPA Developers-
>
> A third attempt is now being made to cut the 1.0.0 release after the
> discussion at http://www.nabble.com/-VOTE--Approve-OpenJPA-1.0.0-
> release-tf4306366.html
Hi,
It seems like the board report directory should be in the dir above trunk, no?
Currently, we have a copy in trunk and in the 1.0.0 branch.
-Patrick
On 8/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: clr
> Date: Thu Aug 23 14:34:40 2007
> New Revision: 569154
>
> URL: http://
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
Sorry, I was thinking of BigDecimal. Scratch that objection.
-Patrick
On 8/23/07, Evan Ireland <[EMAIL PROTECTED]> wrote:
> Patrick,
>
> In what sense does BigInteger have a lack of precision?
>
> > -Original Message-
> > From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> > Sent: Friday, 2
Patrick,
On 8/23/07, Patrick Linskey <[EMAIL PROTECTED]> 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. primitiv
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: kern
Patrick,
In what sense does BigInteger have a lack of precision?
> -Original Message-
> From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> 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.
>
> Person
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 <[EMAIL PROTECTED]> wrote:
> Patrick,
>
> On 8/23/07, Patri
Patrick,
On 8/23/07, Patrick Linskey <[EMAIL PROTECTED]> 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 l
> Gathering more info about the exceptions are nice thing to do. However, it
> triggers lots of unnecessary execution since they will fail the same way. It
> would be nice to see the exception immediately, then correct the problem and
> continue on. Of course, most of these scenarios will be happen
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:[EMAIL PROTECTED]
Sent: August 23, 2007 1:17 PM
To: dev@openjpa.apache.org
Subject: Re: BigInteger as @I
> 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
avo
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 en
Hi Guys,
Can someone help me interpret a limitation specified in section 7.2:
- Once OpenJPA eager-joins into a class, it cannot issue any further
eager to-many joins or parallel selects from that class in the same query.
To-one joins, however, can recurse to any level.
So, if I have th
Patrick,
Thanks for the explanation!
Gathering more info about the exceptions are nice thing to do. However, it
triggers lots of unnecessary execution since they will fail the same way. It
would be nice to see the exception immediately, then correct the problem and
continue on. Of course, most of t
Let's just do another respin and pull it in. The code has already been
committed and it does fix an obscure NPE with discriminator values assuming
the default type of String. Thanks for being flexible. We just need to
ensure that the vote completes before you take off on vacation, right? :-)
K
19 matches
Mail list logo
