[
https://issues.apache.org/jira/browse/JDO-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574800#comment-14574800
]
Craig L Russell commented on JDO-737:
-------------------------------------
If we adopt this approach we would e.g. have:
Integer datastoreTimeoutMillis();
and
Query datastoreTimeoutMillis(Integer value);
I think this is ok for all of the methods that are property-like, but others
are an issue:
setClass: don't make it fluent
setCandidates: ditto
declareImports: add Query imports(String)
declareParameters: ditto
declareVariables: ditto
setIgnoreCache: add Query ignoreCache(boolean)
setUnique: no change; handle this with the execute options?
setResultClass: no change; handle this with the execute options?
addExtension: add Query extension(String, Object) and extension(Map)
setUnmodifiable: add Query unmodifiable (boolean)
addSubquery with overloads: add Query subquery(overloads)
setDatastoreReadTimeoutMillis: add Query datastoreReadTimeoutMillis(Integer)
setDatastoreWriteTimeoutMillis: add Query datastoreWriteTimeoutMillis(Integer)
setSerializeRead: add Query serializeRead(boolean)
> 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)
