Return-Path: 
 <dev-return-8847-apmail-cayenne-dev-archive=cayenne.apache.org@cayenne.apache.org>
X-Original-To: apmail-cayenne-dev-archive@www.apache.org
Delivered-To: apmail-cayenne-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8AE4FD39D
	for <apmail-cayenne-dev-archive@www.apache.org>;
 Tue, 11 Dec 2012 18:11:57 +0000 (UTC)
Received: (qmail 54436 invoked by uid 500); 11 Dec 2012 18:11:57 -0000
Delivered-To: apmail-cayenne-dev-archive@cayenne.apache.org
Received: (qmail 54398 invoked by uid 500); 11 Dec 2012 18:11:57 -0000
Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cayenne.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cayenne.apache.org>
List-Post: <mailto:dev@cayenne.apache.org>
List-Id: <dev.cayenne.apache.org>
Reply-To: dev@cayenne.apache.org
Delivered-To: mailing list dev@cayenne.apache.org
Received: (qmail 54386 invoked by uid 99); 11 Dec 2012 18:11:57 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2012 18:11:57 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of johnthuss@gmail.com
 designates 209.85.212.43 as permitted sender)
Received: from [209.85.212.43] (HELO mail-vb0-f43.google.com) (209.85.212.43)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2012 18:11:52 +0000
Received: by mail-vb0-f43.google.com with SMTP id fs19so4941413vbb.16
        for <dev@cayenne.apache.org>; Tue, 11 Dec 2012 10:11:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=SoSTmMvbE9vHZio/9zx1ni9/CF+hSg+15b85RkayepI=;
        b=MSRP6O57Na1JAI+mRL/HH8JY8rzU5NLjxpmLUhSEtSCPgrJ/CHe0T8ZoPevEASmTxR
         E4zMLojslIwP5zARbMPUemP34bGmh5EW1nwo4frhlweNNfL+kIG+PL2wQw5gmz3P2iJH
         uM6cymHLGEsYgfNEAY4ZeZ6ydAoVELBDXQpv3iMdF5q5RkbVHqh4LHBP/u40/1lCaaOf
         Re+lrSRX7lBKBo9TjNErdT5CX+OvOyNCoR9zbHHfqZD7LUX/ODxj80KgBMQ0xsgBmpt7
         cqYwKi+10iMweI7+yqtO2Rw63ItqFw2ea3PSYgicmvfEeKsqHnFcZKcFS8xWDbkt9LwX
         +eag==
MIME-Version: 1.0
Received: by 10.52.17.177 with SMTP id p17mr10159930vdd.87.1355249491839; Tue,
 11 Dec 2012 10:11:31 -0800 (PST)
Received: by 10.58.214.161 with HTTP; Tue, 11 Dec 2012 10:11:31 -0800 (PST)
In-Reply-To: <CC96F323-33E7-4D33-842D-5794C4BCB5AA@objectstyle.org>
References: <JIRA.12438379.1255819938002@arcas>
	<JIRA.12438379.1255819938002.10694.1355119521925@arcas>
	<3BC2AAD8-0A4D-4215-AEF3-C23B4E93607E@objectstyle.org>
	<CAOUwSGta1YE=6eJhANX4AmMu43_Z93-FrggPyVnwgZe7TpMCbg@mail.gmail.com>
	<CC96F323-33E7-4D33-842D-5794C4BCB5AA@objectstyle.org>
Date: Tue, 11 Dec 2012 12:11:31 -0600
Message-ID: 
 <CAOUwSGvBOoRp1=Z60ua5=U3jM+A8+q6SEZR9i+5NH=p+SJZWmA@mail.gmail.com>
Subject: Re: [jira] [Updated] (CAY-1294) Generify query
From: John Huss <johnthuss@gmail.com>
To: "dev@cayenne.apache.org" <dev@cayenne.apache.org>
Content-Type: multipart/alternative; boundary=bcaec5040a448b0a1c04d0979c20
X-Virus-Checked: Checked by ClamAV on apache.org

--bcaec5040a448b0a1c04d0979c20
Content-Type: text/plain; charset=ISO-8859-1

That's what I was thinking too this morning.


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
> >>>
> >>
> >>
>
>

--bcaec5040a448b0a1c04d0979c20--