Maybe to resolve it we call the new method something else? E.g.: List<T> select(Select <T> query)
On Dec 10, 2012, at 6:54 PM, John Huss <[email protected]> wrote: > The interface type is not sufficient to disambiguate the overloading. If > you overload it this way the compiler complains "the method performQuery() > is ambiguous" since SelectQuery is both a Query and a Select<T>. It can > only resolve the issue if you query is declared this way: > > Select<T> query = new SelectQuery... > > which prevents you from using any of the API in SelectQuery. I suppose you > could provide builder (with the fluent API we've discussed) that returned > the final result as Select<T>, but again then at that point you would have > an opaque object that you couldn't easily modify. That's generally how > builders work though, so it might be fine; but existing code would have to > be rewritten to use it. > > If we stick with the overloading using SelectQuery<T> we could still add > other overloads for specific types as well, it just gets repetitious. > > > On Mon, Dec 10, 2012 at 4:09 AM, Andrus Adamchik > <[email protected]>wrote: > >> A great approach to break our deadlock of on this feature! But maybe we >> leave a bit more room for future extension by defining an interface for >> generics selecting query: >> >> interface Select<T> >> >> SelectQuery<T> extends QualifiedQuery implements Select<T> >> >> List<T> performQuery(Select <T> query) >> >> Then we can reuse the same ObjectContext method for other queries we might >> invent. >> >> Andrus >> >> >> On Dec 10, 2012, at 9:05 AM, John Huss (JIRA) <[email protected]> wrote: >>> [ >> https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] >>> >>> John Huss updated CAY-1294: >>> --------------------------- >>> >>> Attachment: >> 0002-Minimize-compiler-warnings-about-missing-type-parame.patch >>> >> 0001-Add-type-parameter-to-SelectQuery-to-indicate-query-.patch >>> >>> Here is an implementation of a generified SelectQuery. It doesn't >> require any new API - there is simply an overloaded version of >> ObjectContext.performQuery for SelectQuery<T> that returns List<T>. >>> >>> <T> List<T> performQuery(SelectQuery<T> query); >>> >>> The <T> is unbounded because it has to support DataRows in addition to >> Persistent objects. The end result of course is that you can avoid having >> to cast the query result from List to List<Artist> and you avoid the >> compiler warning. This seems like a simple win - any objections? >>> >>> I also added a static method to create an instance because if you use >> this you can avoid repeating the class name twice, as in new >> SelectQuery<Artist>(Artist.class, null), which feels very tedious. So if >> you prefer you can call SelectQuery.from(Artist.class, null) instead and it >> will infer List<Artist> as the query result type. >>> >>> public static <T> SelectQuery<T> from(Class<T> rootClass, Expression >> qualifier); >>> >>>> Generify query >>>> -------------- >>>> >>>> Key: CAY-1294 >>>> URL: https://issues.apache.org/jira/browse/CAY-1294 >>>> Project: Cayenne >>>> Issue Type: Improvement >>>> Components: Core Library >>>> Reporter: Ari Maniatis >>>> Assignee: Andrus Adamchik >>>> Fix For: Undefined future >>>> >>>> Attachments: >> 0001-Add-type-parameter-to-SelectQuery-to-indicate-query-.patch, >> 0002-Minimize-compiler-warnings-about-missing-type-parame.patch >>>> >>>> >>>> Although most of the generics work has been completed for 3.0, 'query' >> is still largely untouched. From a mailing list post by Andrus, here are >> possible query result types: >>>> ? extends Persistent >>>> ? extends Object (unfinished POJO implementation) >>>> CayenneDataObject (as in "generic persistence" [1]) >>>> DataRow >>>> scalar >>>> Object[] (a mix of scalars and any of the above) >>>> Certainly having a typed result list would be very useful in the most >> common case of <? extends Persistent>. >>> >>> -- >>> This message is automatically generated by JIRA. >>> If you think it was sent incorrectly, please contact your JIRA >> administrators >>> For more information on JIRA, see: >> http://www.atlassian.com/software/jira >>> >> >>
