Started using the new API. Very cool! One note - maybe in addition (instead of?) to Cayenne.objectForQuery we need Cayenne.objectForSelect(..) ?
On Dec 14, 2012, at 10:56 AM, Andrus Adamchik <[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. > > 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 >>>>>> >>>>> >>>>> >>> >>> > >
