Marina Vatkina wrote:
I didn't suggest to remove the existing @Entity annotation - what I
suggested
was to change the @MappedSuperclass to be an @Entity, *and* make it
*abstract*.
The latter will mean that you'll never get its instances back.
I've tested this, but OpenJPA still has
[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491310
]
Abe White commented on OPENJPA-219:
---
1. Yes, clearly we'd use our org.apache.openjpa.lib.util.concurrent.
[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491316
]
Patrick Linskey commented on OPENJPA-219:
-
another way to approach this would be not to cache at all,
and
Hi tbee,
I've only seen bits and pieces of this issue scattered through a
dozen emails. I understand vaguely that you're trying to separate the
persistent field definition from the behavior, but can't really
understand how you're trying to do it.
Would it be possible for you to post a
Marina Vatkina wrote:
This is close to impossible as there are probably CTS tests that use an
@Entity
that extends another @Entity. Are you using JPA in an EE 5 container?
Otherwise
you need to list all antities and mapped superclasses in your
persistence.xml.
I did'n't say this
After a lot of research I found that its possible to get something
like this into the persistence unit info properties
openjpa.ClassTransformerOptions=ScanDevPath=true
(expresses as part of a properties file rather than the equivalent
xml from persistence.xml)
and that results
Note that in OpenJPA, you could fully specify all your relations as
relations between the abstrat entity classes or mapped superclasses (so
AbstractPerson would have a reference to AbstractAddress, etc.) and then
narrow the types of the relations in the subclasses. This would allow
you to create
Patrick Linskey wrote:
Note that in OpenJPA, you could fully specify all your relations as
relations between the abstrat entity classes or mapped superclasses (so
AbstractPerson would have a reference to AbstractAddress, etc.) and then
narrow the types of the relations in the subclasses.
Seems to me that something is wrong here. Maybe the code in
PersistenceProviderImpl should be removing the property?
Maybe the ConfigurationProvider should know about the
property? Maybe this is actually not something that should
be settable in persistence.xml?
#2. Thanks for pointing
On Apr 24, 2007, at 10:39 AM, Patrick Linskey wrote:
Seems to me that something is wrong here. Maybe the code in
PersistenceProviderImpl should be removing the property?
Maybe the ConfigurationProvider should know about the
property? Maybe this is actually not something that should
be
I wonder if this is possibly related to OPENJPA-179 and/or OPENJPA-198?
Although Phill's symptoms are slightly different, he is getting unexpected
behavour just because the schema name is specified. May be completely
unrelated, but the description jogged my memory on this outstanding problem
Maybe I am wrong here let me ask a clarifying question. When executing a find on
an object that has a related object (like this example) does OpenJPA create one
select statement and grab all fields for both objects then parse the results to
build both objects? I assumed it makes one select per
Phill-
On Apr 24, 2007, at 11:42 AM, Phill Moran wrote:
Maybe I am wrong here let me ask a clarifying question. When
executing a find on
an object that has a related object (like this example) does
OpenJPA create one
select statement and grab all fields for both objects then parse
the
[
https://issues.apache.org/jira/browse/OPENJPA-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491423
]
Marc Prud'hommeaux commented on OPENJPA-61:
---
Note that you should make sure that you are really using the
There is nothing special that you need to do. Java EE 5 Tutorial has an example
that uses TableGenerator, but it shouldn't matter much - see
http://java.sun.com/javaee/5/docs/tutorial/doc/PersistenceEJB2.html#wp82561
-marina
saidulu chitipolu wrote:
Hi,
We are using
[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey reassigned OPENJPA-219:
---
Assignee: Patrick Linskey
Reflection: negative caching would be beneficial in
[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491458
]
Patrick Linskey commented on OPENJPA-219:
-
How does this compare to the leaky-patch version?
Reflection:
suspend/resume) and it has recently provided the means to
execute a Runnable in a new Tx (via the runUnderUOW feature)
Yay!
It should be very easy to restructure our existing code to move the
relevant logic to a Runnable.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491470
]
Bret Weinraub commented on OPENJPA-219:
---
The no-leak version is cache v3 although that's a misnomer ; there's
[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret Weinraub updated OPENJPA-219:
--
Attachment: openJPABenchmark.tar.gz
My benchmark code.
Easy to write a new implementation
Can you ask the websphere team to support a Callable also, so
we can easily return a value or throw an exception from the
task?
Seems like for WAS's needs, just supporting Callable would be good
enough, no?
We need to use Runnable at the end of the day in ManagedRuntime, so that
things
Hello,I came accross a problem where my foreign key constraints were being violated because of the SQL insertion order during merge operations. I am aware that OpenJPA does not do any SQL re-ordering to avoid violating foreign key constraints, however, it was trivial to make the needed changes
Do you have an orm.xml (or another mapping.xml file) that might override some
information? Can it be that not all classes are on the classpath? Or can there
be another persistence.xml or orm.xml on the classpath that can affect the
results? As there are plenty of tests that test an entity that
Phill,
This is what the spec says:
3.2.3 Synchronization to the Database
For any entity Y referenced by a relationship from X, where the relationship
to Y has not been annotated with the cascade element value cascade=PERSIST or
cascade= ALL:
...
If Y is detached, the semantics depend
java.lang.IllegalStateException
at org.apache.openjpa.kernel.BrokerImpl.free(BrokerImpl.java:4083)
at org.apache.openjpa.kernel.BrokerImpl.close(BrokerImpl.java:4013)
at org.apache.openjpa.kernel.DelegatingBroker.close
(DelegatingBroker.java:1284)
at
+1 -- I'd prefer to have the binary / source uber-archives outside
of the Maven repro, though that's more due to convention than anything
else.
I agree that it's not worth worrying about this for 0.9.7.
Cheers,
Eddie
On 4/24/07, Michael Dick [EMAIL PROTECTED] wrote:
I'm finally getting
I agree with having a good OOTB experience as well -- such an
experience helps users get started with OpenJPA and is more likely to
have them learning the APIs and using the distro.
Even better, it's all in the ASF family. :)
Eddie
On 4/23/07, Craig L Russell [EMAIL PROTECTED] wrote:
I
It looks like openejb is closing the EntityManager while creating the
query for some reason. You might want to check with them to see why
they might be doing this.
Might they be prohibiting you from running at all outside of the
transaction?
On Apr 24, 2007, at 7:02 PM, Dain Sundstrom
Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
--
Key: OPENJPA-226
URL: https://issues.apache.org/jira/browse/OPENJPA-226
Project: OpenJPA
Issue Type: Improvement
Why are you calling close() during createNamedQuery()?
Turns out that you need to do more work to ensure that the query doesn't
get closed until after it's been executed. This basically means that you
need to have a proxy EM that creates Query instances that have
references to the underlying
[
https://issues.apache.org/jira/browse/OPENJPA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey updated OPENJPA-226:
Attachment: OPENJPA-226.patch
Here's a patch that does this. Thoughts?
Change
Hmm. I wonder if we're really using Maven repositories correctly. Do we
need our dist to be in Maven at all?
I do think that we should have something that's easy to depend on that
pulls in the openjpa-persistence-jdbc module, without making people have
to know about that level of modularity
I am they, the one writing the cmp code in OpenEJB.
On first read of the stack trace I thought as you that, I was the one
close the entity manager, but on a second read I notice it was
OpenJPA calling closeIfNoTx that closes the broker.
On Apr 24, 2007, at 7:02 PM, Dain Sundstrom wrote:
On Apr 24, 2007, at 7:27 PM, Patrick Linskey wrote:
Hmm. I wonder if we're really using Maven repositories correctly.
Do we
need our dist to be in Maven at all?
We don't need to. It was just easy to set up that way.
I do think that we should have something that's easy to depend on that
I do think that we should have something that's easy to
depend on that
pulls in the openjpa-persistence-jdbc module, without making people
have to know about that level of modularity detail.
Why can't they just depend on openjpa-all? That brings
everything in...
It's just a bit odd
Schema attribute for @Table() causes MappingToll validate to throw an exception
---
Key: OPENJPA-227
URL: https://issues.apache.org/jira/browse/OPENJPA-227
Project: OpenJPA
I don't think you want the tarball in maven. Personally I would not look for it
there or go searching my local repo to open and get examples, docs etc. Can we
keep the tarball on OpenJPA and the minimal compile an execution jar on Maven.
Keep in mind that this jar is replicated on maven, corp repo
Yep -- you've gotta keep it open. If you want to support any JPA impl,
you need to have an EM proxy (please please please make it a dynamic
proxy that implements all the interfaces that the proxied thing
implements).
If you're happy tying yourself to OpenJPA (or if you want to optimize
for
38 matches
Mail list logo
