Sounds like a good idea.
On Tue, Dec 18, 2012 at 2:29 AM, Andrus Adamchik <[email protected]>wrote: > 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 > >>>>>> > >>>>> > >>>>> > >>> > >>> > > > > > >
