> The problem with this is that Select<T> is an empty interface, and because > ObjectContext* and SelectQuery are in different packages the Select<T> > interface must be public.
Don't see a problem with that. I was actually thinking of it as public from the beginning. And it can even extend Query (?). Sorry, I omitted the "public" keyword in the pseudo-code of the original message. Andrus On Dec 14, 2012, at 7:37 AM, John Huss <[email protected]> wrote: > The problem with this is that Select<T> is an empty interface, and because > ObjectContext* and SelectQuery are in different packages the Select<T> > interface must be public. So there is nothing preventing someone from > making any class implement Select<T> and then passing it to > objectContext.select(). If these were in the same package, then Select > could have package access and be expected to be internal to cayenne; but > that is not the case. > > Given that, I am in favor of sticking with the original proposal to > override performQuery for SelectQuery<T> only and save the more generic > solution for a release with more dramatic changes that would involve > actually fleshing out a real interface for Select. The override does not > minimize or conflict with any other future improvements in this direction > so there isn't really anything to lose. > > John > > > On Tue, Dec 11, 2012 at 10:58 AM, Andrus Adamchik > <[email protected]>wrote: > >> 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 >>>>> >>>> >>>> >> >>
