cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: [jira] [Updated] (CAY-1294) Generify query
Date Fri, 14 Dec 2012 04:37:21 GMT
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 <andrus@objectstyle.org>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 <johnthuss@gmail.com> 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 <andrus@objectstyle.org
> >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) <jira@apache.org> 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
> >>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message