db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew T. Adams (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-652) Provision of a statically-typed refactor-friendly query capability for JDOQL
Date Thu, 01 Jul 2010 14:55:54 GMT

    [ 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

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.


> 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.

View raw message