On Apr 28, 2008, at 6:16 AM, rlv j wrote:
Isn't your software already combined with openjpa, irrespective of
the
enhancement?
I believe that 'my software' can be compiled to .class files while
being
clearly not a derivative work because they are separable and only use
OpenJPA by linking
Isn't your software already combined with openjpa, irrespective of the
enhancement?
geir
On Apr 28, 2008, at 5:17 AM, rlv j wrote:
As I understand it, OpenJPA modifies your code (in the form of
Java .class
files) to add persistency abilities, presumably adding code from
OpenJPA
to the co
k
On Fri, Feb 29, 2008 at 9:25 AM, Geir Magnusson Jr. <[EMAIL PROTECTED]>
wrote:
On Feb 29, 2008, at 12:13 PM, Patrick Linskey wrote:
How can I tell OpenJPA to ignore it?
Don't ask OpenJPA to enhance it.
How are you invoking the enhancer? It sounds like you're either
oh - fantastic! Thanks
On Feb 29, 2008, at 12:24 PM, Patrick Linskey wrote:
You might want to try setting the openjpa.OrphanedKeyAction to
"exception" -- this might help debug where the issue is coming from.
-Patrick
On Tue, Feb 26, 2008 at 5:22 PM, Geir Magnusson Jr. <[EM
and I took it out :
pthbb:trunk geir$ cd src/main/resources/META-INF/
pthbb:META-INF geir$ grep AbstractControlledListItem persistence.xml
pthbb:META-INF geir$
yet still I get that notification.
geir
-Patrick
On Fri, Feb 29, 2008 at 5:48 AM, Geir Magnusson Jr. <[EMA
After a bit of refactoring, I have a set of entity classes that have a
common abstract ancestor. This ancestor has nothing JPA-ish about it.
However, when I run the enhancer (v1.0.2) I get :
[openjpac] 1003 pu WARN [main] openjpa.Enhance - Type "class
com.joost.model.codes.AbstractCont
We're getting tons of these in production (and in test). OpenJPA
1.0.1 and 1.0.2 :
1677 WARN [main] openjpa.Runtime - Detected possible orphaned
reference to deleted object "125706" in
"com.joost.model.GeneratedThumbnail.videoEnclosure".
In a private chat, Patrick suggested it means
we like "WITH"
geir
On Feb 20, 2008, at 12:15 PM, Patrick Linskey wrote:
+selectWordSet.add("WITH");
+selectWordSet.add("WITH");
Why do we add 'WITH' twice here?
-Patrick
On Tue, Feb 19, 2008 at 9:32 AM, <[EMAIL PROTECTED]> wrote:
Author: mikedd
Date: Tue Feb 19 09:32:05
On Feb 6, 2008, at 11:21 PM, Patrick Linskey wrote:
Hi,
I'd like to get started on building an OpenJPA 1.0.2 release
candidate. There are currently five open issues for 1.0.2; I don't
think that any of them merit delaying a maintenance release.
+1
We should be in production w/ a critical sy
value="native(ForeignKeys=true)"/>
-Patrick
On Feb 4, 2008 2:31 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
That was my conclusion too, but I thought that when I was looking at
the SQL logging, that wasn't the case.
So, as a "best practi
is is because a different transaction deleted the record.
-Patrick
On Feb 3, 2008 3:02 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Single threaded code, 1 tx, my machine, no else one around...
Code :
/*
* first _delete_ the ones we have
*/
for (ShowIns
Single threaded code, 1 tx, my machine, no else one around...
Code :
/*
* first _delete_ the ones we have
*/
for (ShowInsertionPoint ip : list) {
OMUtil.getEntityManager().remove(ip);
}
OMUtil.getEntityManager().flush();
Exception
"separation" between things...
thx
geir
Craig
On Jan 29, 2008, at 8:09 AM, Geir Magnusson Jr. wrote:
As a followup to yesterday...
We're still having problems. The bug seems to move around
depending on data. We see it in 1.0.0 and we don't see it 1.0.1,
but becaus
As a followup to yesterday...
We're still having problems. The bug seems to move around depending
on data. We see it in 1.0.0 and we don't see it 1.0.1, but because
it's a random, intermittent thing that seems to be data dependent, I'm
hoping that the following gives someone an "aha!" and
Can someone shed some light on this message?
4644 pu WARN [main] openjpa.Runtime - Detected possible orphaned
reference to deleted object "169378" in
"com.joost.model.show.Show.overlay".
thanks
geir
, 2008, at 11:35 AM, Geir Magnusson Jr. wrote:
We're getting this again :
Caused by:
org.apache.openjpa.persistence.PersistenceException: The transaction
cannot be committed, because it was already marked for rollback on
ly. The transaction will be rolled back instead. The cause o
We're getting this again :
Caused by:
org.apache.openjpa.persistence.PersistenceException: The transaction
cannot be committed, because it was already marked for rollback on
ly. The transaction will be rolled back instead. The cause of the
rollback-only status is reported in the embedded
I could use the range issue fix :)
On Jan 13, 2008, at 10:04 PM, Patrick Linskey wrote:
I think that the range issue is a pretty big deal, and justifies a
maintenance release.
-Patrick
On Jan 11, 2008 6:18 AM, Kevin Sutter <[EMAIL PROTECTED]> wrote:
Really? It looks like there has only been
I can back out to 1.0.0, I guess.
Thanks so much
geir
On Jan 9, 2008, at 11:53 AM, cxroguy wrote:
Yes, this is OPENJPA-476. It works correctly in the 1.1.0 snapshot.
Geir Magnusson Jr.-3 wrote:
Are there any known bugs w/ the above range/page facilities? I can't
seem to get th
org.apache.openjpa.persistence.InvalidStateException: This operation
cannot be performed while a Transaction is active.
at org.apache.openjpa.kernel.BrokerImpl.close(BrokerImpl.java:4014)
at
org.apache.openjpa.kernel.DelegatingBroker.close(DelegatingBroker.java:
1282)
at
org
.apache
.o
Are there any known bugs w/ the above range/page facilities? I can't
seem to get them to work w/ MySQL (v5.0.41)
geir
t matter?)
Shoving a flush() between the two loops solved it - the two deletes
happened, and then the insert happened. MySQL was happy w/ that.
Is this a JPA issue, or is MySQL misbehaving, or am I being a dodo
somehow?
geir
On Jan 3, 2008, at 10:33 AM, Geir Magnusson Jr. wrote:
On Jan 3, 20
tyHashCode() of the collection instances just prior
to flush / commit.
I did it right before setting, and they are distinct values.
Thanks for the help.
geir
-Patrick
On Jan 2, 2008 9:48 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Sorry - there are a few minor errors in my int
Sorry - there are a few minor errors in my interpretation, which
doesn't change my problem. Commments inline :
On Jan 3, 2008, at 12:08 AM, Geir Magnusson Jr. wrote:
I can't figure out what I'm doing wrong.
I'm using joined inheritance and have as my base table Invent
?) [params=(int) 194591, (String) Geir Magnusson Jr.]
so there it creates a new Agent by making the InventoryItem first,
getting the autogen ID, and using that to add to the Agent table.
Then it makes a new contributor, using that Agent (id=194591) :
2959 pu TRACE [main] openjpa.jdbc.SQL -
ok - we'll try that.
thx
On Nov 27, 2007, at 11:30 AM, Patrick Linskey wrote:
I think you need to re-compile and re-enhance your classes.
That error msg sucks.
-Patrick
On Nov 27, 2007 7:22 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I have no idea how to ask the quest
I have no idea how to ask the question of what this might be... can
someone give me a hint? This was working. We're doing minor schema
tweaks, so that might have caused this, but we don't know for sure.
Caused by: java.lang.IllegalArgumentException
at
com
.joost
I upgraded about 2 weeks ago. Spaces are a little wonky, but
otherwise, no probs that I can think of.
geir
On Nov 24, 2007, at 3:32 PM, Craig L Russell wrote:
Anyone here have any experience (good or bad) with Leopard? I'm
personally not going to upgrade at least until Java 6 is available
is more to your situation than your
description to Craig.
-Patrick
On Nov 17, 2007 5:12 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Nov 17, 2007, at 7:49 PM, Patrick Linskey wrote:
I think that there was a bit more to it... I think that you were
also
trying to do something that req
needs it's own PK. But B doesn't need to
know A's PK for the action it takes in the @PostPersist method.
-Patrick
On Nov 17, 2007 12:26 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Nov 16, 2007, at 3:00 PM, Craig L Russell wrote:
Hi Geir,
It still isn&
convenient.
geir
Craig
On Nov 15, 2007, at 1:59 PM, Geir Magnusson Jr. wrote:
On Nov 15, 2007, at 4:41 PM, Geir Magnusson Jr. wrote:
On Nov 15, 2007, at 4:34 PM, Pinaki Poddar wrote:
persist() has in it a new, unmanaged entity.
a) If persist(a) is failing on b, what is the ca
-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 15, 2007 1:41 PM
To: dev@openjpa.apache.org
Subject: Re: @PostPersist woes
On Nov 15, 2007, at 4:34 PM, Pinaki Poddar wrote:
persist() has in it a new, unmanaged entity.
a) If persist(a) is failing on b, w
On Nov 15, 2007, at 4:41 PM, Geir Magnusson Jr. wrote:
On Nov 15, 2007, at 4:34 PM, Pinaki Poddar wrote:
persist() has in it a new, unmanaged entity.
a) If persist(a) is failing on b, what is the cascade type
specified on
relation a.b?
I'm not actually sure that it's faili
know that when I change things so that I
have an unmanaged b, it fails.
b) what is the identity definition on b?
c) if b is using auto-assigned GeneratedValue or its id is being set
by
application?
-Original Message-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday
GeneratedValue or its id is being set
by
application?
auto-assigned
geir
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 15, 2007 11:10 AM
To: dev@openjpa.apache.org
Subject: @PostPersist woes
Woe is me :)
I'm using @PostPersist to create
.apache
.openjpa.kernel.StateManagerImpl.accessingField(StateManagerImpl.java:
1434)
[junit-coverage] at
com.joost.model.InventoryItem.getId(InventoryItem.java)
[junit-coverage] at
com.joost.model.InventoryItem.initPublicIdIfNull(InventoryItem.java:331)
[junit-coverage]
On Nov 15, 2007, at 2:10 PM, Geir Magnusson Jr. wrote:
Woe is me
Woe is me :)
I'm using @PostPersist to create some kind of machine-generated data
for entities on insert, and I'm running into the following problem
when an entity for which I called persist() has in it a new, unmanaged
entity.
[junit-coverage] Caused by: error> org.apache.openjpa.util.In
te:
Hmm. Looking at 2.1.8.3.2, it seems that unidirectional ManyToOnes
are
legal. Maybe there's a bug in OpenJPA when putting a unidirectional
ManyToOne into a secondary table or something, or maybe it's just a
bug in all unidirectional ManyToOne cases.
-Patrick
On Nov 5, 2007 6:02
007 5:26 PM, Marina Vatkina <[EMAIL PROTECTED]> wrote:
You need to have @OneToMany(mappedBy="show") - otherwise you get 2
unidirectional relationships, while you are trying to make them
bidirectional.
Regards,
-marina
Geir Magnusson Jr. wrote:
To review, I have three tables :
er of a @OneToMany.
Why?
-Patrick
On 11/5/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
To review, I have three tables :
Show, InputFile and a join table, Show2InputFile.
Show happens to be a subclass of InventoryItem using JOINED
inheritance strategy. Not sure if that matters. (
that @OneToOne, @OneToMany, @ManyToMany, and @ManyToOne
are JPA annotations, not ER annotations. The concepts differ a bit.
-Patrick
On Nov 5, 2007 11:33 AM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Nov 5, 2007, at 2:07 PM, Patrick Linskey wrote:
What happens if you just use a
ntent owner may
give us updated source material - say they have a new transcoding.
We want to add a new InputFile into the database, point it at the
Show, but the Show itself doesn't care about it's source.
Does that help?
eir
-Patrick
On Nov 5, 2007 10:40 AM, Geir Magnusson
are reasons, and its intentional.
What happens if you just use a @OneToOne instead of the @ManyToOne?
The problem is that it's not OneToOne
-Patrick
On Nov 5, 2007 9:16 AM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Nov 5, 2007, at 11:48 AM, Patrick Linskey wrote:
Hi,
way? Show is a subclass in a JOINED inheritance strategy, if
that makes any difference.
geir
-Patrick
On Nov 5, 2007 8:08 AM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I'm a newbie, so forgive me if I'm not asking the question the right
way
I'm a newbie, so forgive me if I'm not asking the question the right
way.
I have a join table in my DB :
+-+--+--+-+-+---+
| Field | Type | Null | Key | Default | Extra |
+-+--+--+-+-+
Apache can still have a formal representation on the EG.
We do feel the technology is good - the problem is that Sun is, in
our opinion, in violation of the JSPA and therefore shouldn't be able
to lead any new JSRs until the problem is fixed.
But don't let that stop you from participating.
46 matches
Mail list logo
