[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884303#action_12884303
]
Matthew T. Adams commented on JDO-652:
--------------------------------------
While I like the current discussion on the fluent query api and think that we
should continue to pursue this idea, I'm afraid that its post facto nature
might be a hindrance to its adoption. That is, a developer has to compile (and
enhance, I suspect) his PC objects in order to get the fluent query objects; he
can't develop persistent objects and use the fluent query ones in the same
module if they require compilation and enhancement. It's kind of a
chicken-and-egg problem, and the only solution I see is to develop the
persistent objects in one module and use fluent query objects in a separate one
that depends on the module with the persistent objects.
I think that developers will want to have query objects and methods available
to them in the same module; the only way I see that happening is to leverage
technologies like Spring Roo, which limits the developers choice of IDE.
Again, I support the fluent query api as discussed in this issue, but I think
we should also create a conventional query api that bites the bullet and,
unfortunately, uses strings for field names that has overloads that take
java.lang.reflect.Field objects, which opens the door in the event that
typesafe means of reflective access to fields as requested in Sun bugs 5043025
and 6915224 becomes a reality.
It did occur to me while writing this that the enhancer could be leveraged
somehow to optionally examine the field names given in the conventional query
api to do field name existence checking. While it's not typesafe at java
compile time, it could at least be typesafe at enhancement time, which most
people do one right after the other.
Thoughts?
> Provision of a statically-typed 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.
