[
https://issues.apache.org/jira/browse/JDO-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593701#comment-14593701
]
Andy Jefferson edited comment on JDO-736 at 6/20/15 8:30 AM:
-------------------------------------------------------------
1 and 2 are in SVN.
So 3 and 4 having binding on the query would imply
setParameters(Map namedParamMap);
setParameters(Object... numberedParamValues);
Not yet in SVN.
Another point to consider. Based on current SVN code, Query has
setResult(String) or result(String), whereas JDOQLTypedQuery (which came from
the DataNucleus prototype) has the result only specifiable in the execute
methods (since that way we can distinguish a query returning List<Object> from
a query returning List<Object[]>). With the String form of a result (in
traditional javax.jdo.Query) we cannot know if there are more than 1 result
expression, hence use of generics for that case is impossible (without forcing
the user to input multiple strings, for each of the result expressions).
Options for rationalising this are
a). Keep both as now, so the result is specified on the Query object via
result(...), whereas with JDOQLTypedQuery it is only specified on execute().
b). Remove the result expressions from JDOQLTypedQuery execute() methods and
just have via "result(...)" and then we have consistency, with the result
specified on the JDOQLTypedQuery object (but then we don't distinguish single
and multiple result clauses and a user has to cast for multiple result cases).
I'd tend towards "b" solely because it gives better read-across between generic
javax.jdo.Query and javax.jdo.JDOQLTypedQuery specification, and with the
result being specified prior to execute we can compile() it. Any opinion?
was (Author: andy):
1 and 2 are in SVN.
So 3 and 4 having binding on the query would imply
setParameters(Map namedParamMap);
setParameters(Object... numberedParamValues);
Not yet in SVN.
Another point to consider. Based on current SVN code, Query has
setResult(String) or result(String), whereas JDOQLTypedQuery (which came from
the DataNucleus prototype) has the result only specifiable in the execute
methods (since that way we can distinguish a query returning List<Object> from
a query returning List<Object[]>).
Options for rationalising this are
a). Keep both as now, so the result is held on the Query object, whereas with
JDOQLTypedQuery it is only specified on execute().
b). Remove the result from JDOQLTypedQuery and just have via "result(...)" and
then we have consistency, with the result specified on the JDOQLTypedQuery
object (but we don't distinguish single and multiple result clauses - not such
a bad thing).
I'd tend towards "b".
> Change Query API to make use of generics to avoid casting execute() results
> ---------------------------------------------------------------------------
>
> Key: JDO-736
> URL: https://issues.apache.org/jira/browse/JDO-736
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
> Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-736.patch
>
>
> The query API is dated, requiring casting of results to the required type.
> Let's make use of generics etc and remove the pain. This will mean changing
> the API so that the resultClass (and possibly more) will need passing into
> the
> execute() method(s). Could also specify parameters via setter rather than
> just on the execute.
> See JDO-652 also, we need to have a consistent way of executing queries
> whether created using strings or typesafe, so that no casting of results is
> needed with either
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
