openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Stultz <>
Subject Re: Fetch plan question
Date Sat, 12 Dec 2009 20:34:11 GMT
On Fri, Dec 11, 2009 at 5:27 PM, Pinaki Poddar <> wrote:

> Please try in a realistic setup if the fix works. I just ran a version of
> your test to verify the fix.
> The best that I can tell, the "real application" code that was failing is
now succeeding. I now have a different crash after the previously failing
code. I had thought it might have something to do with the classes being
enhanced for 1.2.1. I believe I have successfully enhanced my classes with
2.0M3. I'm getting this error:

org.apache.openjpa.persistence.ArgumentException: The specified parameter of
type "class com.sixdegreessoftware.apps.rss.model.Case" is not a valid query
        at org.apache.openjpa.kernel.QueryImpl.execute(
        at org.apache.openjpa.kernel.QueryImpl.execute(
        at org.apache.openjpa.kernel.QueryImpl.execute(

from my code that looks like this:

*private* *void* loadScheduledAssignments(List<Case> caseList) {

Query query = ExecutionResources.*getEntityManager*().createQuery("select o
from ScheduledAssignment as o" +

" join fetch o.caze" +

" left join fetch o.brokenRuleLookup" +

" where o.caze in (:cases)" +

" order by o.role.printOrder, o.user.lastName, o.user.firstName,

query.setParameter("cases", caseList);

List<ScheduledAssignment> resultList = query.getResultList();

caseList is populated with 2 cases and runs fine the first time through. The
second time it fails (with one case in list) and fails all subsequent times
(with the original 2 cases). If this is completely unrelated to your fix,
then I guess I'm good, but I'd like to perform the previously failing
operation without running into another snag before saying the fix was
successful. I'm tired of battling with it for now.

The fix (or the error) has nothing to do with FetchPlan -- it is some other
> internal optimization that caused the AOOB exception.
> So is there no hope for avoiding it in 1.2.1?

Daryl Stultz
6 Degrees Software and Consulting, Inc.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message