Here we present some changes to the JDO Query API that are coming in version 3.2 of the spec. Comments should be directed ASAP to the Apache JDO mailing list if you want any changes to make it in to this next revision.
When you are specifying a JDOQL query using the assorted setter methods you can end up with code like this
Query q = pm.newQuery(Manager.class); q.setFilter("theDepts.contains(dept0) && dept0.manager == this"); q.declareParameters("mydomain.model.Department theDepts"); q.declareVariables("mydomain.model.Department dept0"); q.setOrdering("this.firstName ascending");
Clearly this leaves a lot to be desired in terms of API. In JDO 3.2 you can now do the following
Query q = pm.newQuery(Manager.class) .filter("theDepts.contains(dept0) && dept0.manager == this") .parameters("mydomain.model.Department theDepts") .variables("mydomain.model.Department dept0") .ordering("this.firstName ascending") .setParameters(depts);
So you can chain your specification(s). The other thing of note is that you can now set the parameter values prior to execution. The reason for this comes next.
No casting on execute()
With the former query above, we would execute it as follows
Collection<Manager> managers = (Collection<Manager>) q.execute(depts);
With JDO 3.2 we can execute it like this
Collection<Manager> managers = q.executeList();
I think we can conclude that this is much cleaner. There is no need to cast the result from the execute method, simply using a different execute method based on what your query is expected to return.
Save as a NamedQuery
You can now construct a query, and save it as a named query, so you don’t need to regenerate it. You do that as follows
Query q = pm.newQuery("SELECT FROM Person WHERE this.lastName == :surname"); q.saveAsNamedQuery("FindPeopleWithSurname");
So from that point forwards when you need that query, you can do the following
Query q = pm.newNamedQuery(Person.class, "FindPeopleWithSurname");