[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931418#action_12931418
]
Andy Jefferson commented on JDO-652:
------------------------------------
Other thing to consider : what type of access do we want to persistable members
(field/properties) ? There are two options, clearly
1. fields - "candidate.myField" - the only problem with this is that they have
to be initialised in the "Query" class, and if we have recursion then this just
recurses in the constructor of the query class. So we'd need a way of
delimiting the depth of the possible querying so we don't get stack overflows.
DN 2.2 M3 imposes a depth of 5.
e.g tq.orderBy(cand.name.asc());
2. properties - "candidate.myField()" - this has no such drawback. DN 2.2 M3
allows this if you specify the javac argument "-AqueryMode=PROPERTY".
e.g tq.orderBy(cand.name().asc());
Recommend the latter option, but allow implementations to provide both if
desired
> 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.
