[
https://issues.apache.org/jira/browse/JDO-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson updated JDO-737:
-------------------------------
Attachment: JDO-737.patch
Basic implementation using Option 1 for primary query specification methods.
Could optionally add subquery(...), candidates(...), etc. Similarly the result
is not specifiable using these since I'd expect the execute methods to change
so that we can get rid of the casting nonsense.
> Change Query API to be "fluent"
> -------------------------------
>
> Key: JDO-737
> URL: https://issues.apache.org/jira/browse/JDO-737
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
> Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-737.patch
>
>
> Further to JDO-736 it would be nice to redesign the Query class to have the
> setter methods as FLUENT. I see two ways of achieving this
> Option1
> Query q =
> pm.newQuery(Person.class).filter("firstName.startsWith('F')").orderBy("firstName");
> So we add a subset of the setters as methods without "set" so as to align
> further with the typesafe variant in JDO-652. The existing setXXX methods can
> be deprecated.
> Option2
> Query q =
> pm.newQuery(Person.class).setFilter("firstName.startsWith('F')").setOrdering("firstName");
> So we change the return type of (some of) the existing setters. Existing JDO
> code will need to be recompiled due to the return type change.
> What is decided here needs to coordinate with JDO-652 so that, for example,
> if JDO-652 comes up with an API like (as currently)
> query.filter(cand.value.lt.40).orderBy(cand.name.asc())
> then this issue matches the API method names, so using the String-based API
> for the same resultant query the user would do
> query.filter("this.value < 40").orderBy("this.name ASC");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
