Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Message-ID: <13925390.74381289226014019.JavaMail.jira@thor>
Date: Mon, 8 Nov 2010 09:20:14 -0500 (EST)
From: "Matthew T. Adams (JIRA)" <jira@apache.org>
To: jdo-dev@db.apache.org
Subject: [jira] Commented: (JDO-652) Provision of a typesafe
 refactor-friendly query capability for JDOQL
In-Reply-To: <8636188.18591271057620534.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Matthew T. Adams commented on JDO-652:
--------------------------------------

Andy wrote:
1. Naming convention for generated "Query" classes. Currently prefixed by "Q" in this prototype 
2. Way of obtaining candidate, parameter, variable, subquery. If the user wants to access a field then they need to cast to the expression type. See the blog entry for details. Ideally would like to avoid casting 
-----

RE 1:  My personal recommendation for the the "Query" classes is to append the word Query to end of the type.  Instead of QProduct, it would be ProductQuery.

RE 2:  I've been following your blog entries on this development work, and I agree on avoiding casting.  Would it be possible to provide a method in the Q class that the user can call instead of casting?  Perhaps a getField() method in the right place that returns a java.lang.reflect.Field.  I'm not sure where the right place is yet, but in that method, the cast can take place and at least the user wouldn't have to do any casting.  Thoughts?

> 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
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.