Issue Details (XML | Word | Printable)

Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Andy Jefferson
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Provision of a typesafe refactor-friendly query capability for JDOQL

Created: 29/Apr/14 08:24 PM   Updated: 23/Aug/14 08:31 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 30/Apr/14 09:30 AM - edited
Questions to be discussed/resolved :

1. Should we allow parameters to be set on the Query, or only on the execute ? If we remove from the execute then it minimises the API (less execute methods needed). What is the benefit (if any) of specifying on execute ?

2. Should we do like JPA and create a TypesafeQuery through TypesafeQueryBuilder or the PMF, and then convert it to a Query via PM.newQuery(TypeafeQuery) ? Or should we do as now and have PM.newTypesafeQuery() ?

3. Should we allow a Query to be saved under a name programmatically ? e.g
Query q = pm.newQuery(...);
... q.execute();
so then the query can be used by a different PM.

4. Existing Query interface should have its execute() methods updated to support generics
List<Candidate> results = q.executeList();
Candidate cand = q.executeUnique();
List<ResultType> results = q.executeList(ResultType.class);
ResultType result = q.executeUnique(ResultType.class);

5. Once 4 is done then the execute() methods on TypesafeQuery should mirror those also.

6. The typesafe query requires the "Q" classes to provide fluent API for query construction. This is currently envisaged to operate using an annotation processor. The current DataNucleus processor only handles annotated classes. We should make use of the "init" method of the annotation processor to detect classes specified via XML (persistence.xml, package.jdo files)

Anything else?

Andy Jefferson added a comment - 25/May/14 02:31 PM
To aid the commonality between Query and TypesafeQuery we could move all methods
to a Helper/Builder class, so would do

instead of

This would mean that the majority of methods would be common across those two classes (particularly if we move the parameter value setting to be setParameter() on Query, and if we commonise the execute methods on both).

Andy Jefferson added a comment - 27/May/14 02:51 PM
Considering result() expressions and execute(). Do we specify the result in the execute() call like now,

or do we have
result(Expression... exprs)
result(boolean distinct, Expression... exprs)
List<T> executeList();
T executeUnique();
<R> List<R> executeResultList(Class<R> resultCls);
<R> R executeResultUnique(Class<R> resultCls);
List<Object> executeResultList();
Object executeResultUnique();

Andy Jefferson added a comment - 27/May/14 02:52 PM
Considering parameters,
1. do we do like now and add clearParameters() to clear any parameter values that are set,
2. add an extra argument to the execute() methods with a Map of parameters

Andy Jefferson added a comment - 23/Aug/14 08:31 PM
Consider renaming TypesafeQuery to JDOQLTypedQuery since it only applies to JDOQL (all of the expressions are explicitly for that), and change method on PM to be
JDOQLTypedQuery<T> newJDOQLTypedQuery(Class<T> cls);