[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL

["Matthew T. Adams (JIRA)" <ji...@apache.org>]

    [ 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