[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018356#comment-13018356
]
Matthew T. Adams commented on JDO-652:
--------------------------------------
After discussing on the conf call Fri Apr 9, we considered the separation of
the query definition from the persistence manager connected to which the query
definition is executed. It became evident that there is a separation of
concerns between the definition or criteria of the query and the PM against
which it should execute.
Instead of a TypesafeQuery<T>, perhaps the class could have a name that
reflects the fact that it's a query definition, like
TypesafeQueryDefinition<T>, TypesafeQueryCriteria<T>, or, considering that
we're in Java and type safety is inherent, I'd move to drop the prefix
"Typesafe" from the name and go with just something like QueryCritieria<T>. The
currently proposed "Q" classes could be called XxxCriteria ("TeamCriteria" in
this example).
It should also be abled to be obtained by the PMF or the PM. New PMF methods:
// proposed new methods on PMF
1. <T> QueryCriteria<T> newQueryCriteria(Class<T> clazz);
2. Various overloads to execute the given QueryCriteria using the PM given by
PMF.getPersistenceManagerProxy()
New methods could be added to PM to allow for the execution of the query using
that PM:
// methods on PM
1. <T> QueryCriteria<T> newQueryCriteria(Class<T> clazz);
2. Various overloads to execute the given QueryCriteria using this PM.
I see two options for methods that execute these queries. First, only put the
execution methods (execute, update, delete) on the PM to keep the number of
overloads down, or second, provide overloaded execution methods (execute,
update, delete) on the QueryCriteria classes, one set of which takes a PM and
delegates to its appropriate execution method, and another set of which does
not take a PM and delegates to the PM given by
PMF.getPersistenceManagerProxy(). The choice of which option comes down to how
many overloaded methods there would be.
Additionally, if such overloaded execution methods are provided on the
QueryCriteria<T> class, should the ones taking no PM execute against the PM
returned from PM.getPersistenceManagerProxy() or, if the QueryCriteria was
obtained from a PM, the PM from which it came?
> Provision of a typesafe refactor-friendly query capability for JDOQL
> --------------------------------------------------------------------
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
> Reporter: Andy Jefferson
> Fix For: JDO 3 maintenance release 1
>
> Attachments: typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
