Set <property name="openjpa.jdbc.QuerySQLCache", value="false"/>
Daryl Stultz wrote: > > On Fri, Dec 11, 2009 at 5:27 PM, Pinaki Poddar <[email protected]> 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 > parameter. > at > org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1436) > at > org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQLExecutor.executeQuery(PreparedSQLStoreQuery.java:113) > at > org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1001) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:859) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:790) > at > org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525) > at > org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:288) > at > org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:300) > > 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, > o.user.middleInitial"); > > 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. > http://www.6degrees.com > mailto:[email protected] > > ----- Pinaki -- View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4158093.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
