Is there anything wrong with the following query?
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM MailingList l JOIN l.subscribers m)
OpenJPA (0.9.6) parses this correctly, but can't seems to be missing the
JOIN clause or some
[
https://issues.apache.org/jira/browse/OPENJPA-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter reassigned OPENJPA-149:
Assignee: Kevin Sutter
non-jta-data-source must be specified in WebSphere environments
[
https://issues.apache.org/jira/browse/OPENJPA-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter updated OPENJPA-149:
-
Fix Version/s: 0.9.7
Priority: Blocker
Affects Version/s: 0.9.6
I am
[
https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter updated OPENJPA-5:
---
Fix Version/s: 1.0.0
Affects Version/s: 0.9.0
0.9.6
OpenJPA doesn't
[
https://issues.apache.org/jira/browse/OPENJPA-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter reassigned OPENJPA-165:
Assignee: Kevin Sutter
QueryImpl.setFirstResult does not take already set maxResults
[
https://issues.apache.org/jira/browse/OPENJPA-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter updated OPENJPA-165:
-
Fix Version/s: 0.9.7
I've discussed this problem with Jonathan and we should have a patch
Just curious,
Has there been any testing with Java 2 Security enabled and OpenJPA? I'm
hitting a semi-intermittent problem (it doesn't seem to show up on all
machines) which results in an NPE coming out of the
javax.persistence.Persistence.createEntityManager method. I know we have no
control
EntityManager.getReference() returns an object of a wronc class
---
Key: OPENJPA-171
URL: https://issues.apache.org/jira/browse/OPENJPA-171
Project: OpenJPA
Issue Type: Bug
The primary reason was the license, Hibernate is LGPL and it's not
compatible with the Apache license. But we've found some other benefits
during the migration.
For us an important one is the good control OpenJPA gives you on the flush.
Theoretically you can do the same thing with Hibernate but
Hi,
John is having some problems with posting to the open-jpa-dev mailing list
via his e-mail account, so I am posting this message for him so that we can
start this conversation...
=
Fellow OpenJPAers, :)
As Craig had brought up (through Scott
I am fairly certain that the only way OpenJPA will ever think that a
native (i.e., SQL) query is not a select query is if it doesn't start
with select.
Is it possible that you didn't recompile the class after
experimenting with the quoteForUpdate @NamedNativeQuery? At some
point in the
Roger-
The query looks valid: it sounds like a pretty clear-cut bug. Can you
file a JIRA?
As for a workaround, is there an inverse from MailingList.subscribers
(e.g., Email.mailingList)? If so, then you might be able to re-cast
the query as:
UPDATE Email e SET e.totalDeliveries =
[
https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480455
]
Abe White commented on OPENJPA-171:
---
It would speed things up a lot if you attached a working test case
John-
I just ran a test with a named native query that did a select ...
for update and it worked fine.
One possibility is that our identification of whether the native
query is a select or an update is done by some fairly simplistic
parsing of whether the statement starts with select or
Hi John,
EJB method calling is this:
public Quoteejb testForUpdateQuery(String symbol){
Query q = em.createNativeQuery("quoteForUpdate");
q.setParameter(1,symbol);
Shouldn't you call Query q = em.createNativeNamedQuery("quoteForUpdate");
?
Regards,
Mitesh
Marc Prud'hommeaux wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480510
]
Abe White commented on OPENJPA-171:
---
I attempted to reproduce this in a very simple test case but failed. We'll
Roger,
There is a similar problem already reported under bug OPENJPA-51.
Catalina
On 3/13/07, roger.keays [EMAIL PROTECTED] wrote:
Is there anything wrong with the following query?
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email
Marc,
On 3/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Kevin-
I don't think we've done extensive stand-alone testing with security
enabled, but we have people using OpenJPA in so many different exotic
containers with their attendant security settings, that I'd be a
little surprised if
DSRA9250E: Operation setTransactionIsolation is not allowed during a global
transaction for Shareable Connections.
---
Key: OPENJPA-172
URL:
roger.keays wrote:
Hi Marc,
Marc Prud wrote:
The query looks valid: it sounds like a pretty clear-cut bug. Can you
file a JIRA?
I've filed issue 173: https://issues.apache.org/jira/browse/OPENJPA-173
As for a workaround, is there an inverse from MailingList.subscribers
Craig-
Yes, there do appear to be problems. If I clobber my repository (so
that the latest surefire plugin is downloaded) and try to run the
tests, everything fails with java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap.
I'll try to look into it tonight...
On Mar 13,
Mike-
Thanks for the tip. Adding useSystemClassLoader seems to fix the
problem so I've gone ahead and added that to our pom.xml.
On Mar 13, 2007, at 8:05 PM, Michael Dick wrote:
I think we're running into a side effect of
http://jira.codehaus.org/browse/SUREFIRE-301 (just a guess
22 matches
Mail list logo
