db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig L Russell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
Date Sun, 29 May 2011 23:16:48 GMT

    [ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040897#comment-13040897

Craig L Russell commented on JDO-652:

I like the direction of this api. My comments here might have been expressed by others; I
don't claim ownership of them. ;-)

I like the naming of the Q classes generated during pre-processing. I consider the requirement
to have the persistent classes annotated to be a distraction though. 

I think we need to consider reuse of the query artifacts by different persistence managers,
and also the possibility that the query definition might be stored as a named query. This
leads to needing a factory defined on the PMF, not just the PM. The factory might not be needed
on the PM depending on other considerations (discussed below).

The same query definition could be used by different projections. We could make this explicit
in the api by adding a method to the query definition that returns a different interface like
QueryProjection<R> where R is the class of the result. And the query definition interface
contains a superset of the methods of the query projection interface, reflecting that the
default query projection returns instances of the candidate class.

It isn't clear from the external view whether there is a check to be sure that the filter
applies to properties of the candidate class. I expect that we can make sure that this is
the case by templating the expressions on both the type of the candidate class and the type
of the property.

In order to execute a query, three things are needed: the query definition (including the
projection definition), the persistence manager, and the parameters. I believe that there
is value in allowing parameters to be bound very late, during the execution of the query.
But I also see value in allowing parameters to be bound to a different instance entirely.

If set individually, properties should be type-checked as well. Using the setParameter(name,
value) method on the query definition, I don't see how to check the type. Instead of name,
perhaps a method taking the parameter itself instead of the name.  

It will be good to integrate this new query api into the existing query, but I'll leave that
discussion for later (perhaps once we agree what the new query should look like).

Thinking out loud,

QueryDefinition<T> extends QueryProjection<T> {
void filter(Predicate<T>);
QueryProjection<P> project(Class<P>, projectionList...);
get/set Unmodifiable();

QueryProjection<P> {

QueryExecution<P> {
setParameter(Parameter<Q>, Q);
List<P> executeList(Object... parameters); 
P executeUnique(Object... parameters);
List<P> executeList(Map parameters); 
P executeUnique(Map parameters);
get/set ReadTimeout(int millis);
get/set WriteTimeout(int millis);
get/set Range(int low, int high);
get/set IgnoreCache(boolean);
get/set SerializeRead(boolean);

PersistenceManagerFactory {
QueryDefinition<T> newQueryDefinition(Class<T> candidateClass), boolean unique);
void storeNamedQuery(String name, QueryProjection<?> query);
QueryProjection<?> getNamedQuery(String name);

PersistenceManager {
List<P> executeList(QueryProjection<P>, Object... parameters);
P executeUnique(QueryProjection<P>, Object... parameters);
QueryExecution<P> newQueryExecution(ExecutionProjection<P>);

> 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

View raw message