[ https://issues.apache.org/jira/browse/JDO-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593615#comment-14593615 ]
Craig L Russell commented on JDO-736: ------------------------------------- My $0.02: 1. I think we should have two interfaces for the reasons you state. 2. I don't think we need a separate QueryExecution<T>. I think we've used this as a discussion facilitator but doesn't need to be an explicit interface. But the methods should be on both query interfaces. 3. We currently have several methods that pass parameters to the query. By design, these were all "execute" methods so the implementation could keep the query and bound parameters separate. If we add parameter binding methods then we need to update the "Query newQuery (Object compiled);" description to say what happens to the bound parameters: are they copied to the new query or not. Then we can have simply two variants on parameters: Map and Object... 4. Ditto for deletePersistentAll. By the way, deletePersistentAll should also be usable with a range so you could delete just the first 100 of a thousand objects that pass the filter. > Change Query API to make use of generics to avoid casting execute() results > --------------------------------------------------------------------------- > > Key: JDO-736 > URL: https://issues.apache.org/jira/browse/JDO-736 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck > Reporter: Andy Jefferson > Fix For: JDO 3.2 > > Attachments: JDO-736.patch > > > The query API is dated, requiring casting of results to the required type. > Let's make use of generics etc and remove the pain. This will mean changing > the API so that the resultClass (and possibly more) will need passing into > the > execute() method(s). Could also specify parameters via setter rather than > just on the execute. > See JDO-652 also, we need to have a consistent way of executing queries > whether created using strings or typesafe, so that no casting of results is > needed with either -- This message was sent by Atlassian JIRA (v6.3.4#6332)