Return-Path: 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 25801DF74 for ; Tue, 11 Dec 2012 16:58:43 +0000 (UTC) Received: (qmail 2864 invoked by uid 500); 11 Dec 2012 16:58:43 -0000 Delivered-To: apmail-cayenne-dev-archive@cayenne.apache.org Received: (qmail 2677 invoked by uid 500); 11 Dec 2012 16:58:40 -0000 Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cayenne.apache.org Delivered-To: mailing list dev@cayenne.apache.org Received: (qmail 2650 invoked by uid 99); 11 Dec 2012 16:58:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2012 16:58:39 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.78.103.231] (HELO vorsha.objectstyle.org) (208.78.103.231) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 11 Dec 2012 16:58:33 +0000 Received: (qmail 21647 invoked from network); 11 Dec 2012 17:02:47 -0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by localhost with SMTP; 11 Dec 2012 17:02:47 -0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [jira] [Updated] (CAY-1294) Generify query From: Andrus Adamchik In-Reply-To: Date: Tue, 11 Dec 2012 19:58:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BC2AAD8-0A4D-4215-AEF3-C23B4E93607E@objectstyle.org> To: dev@cayenne.apache.org X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org Maybe to resolve it we call the new method something else? E.g.: List select(Select query) On Dec 10, 2012, at 6:54 PM, John Huss 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. It = can > only resolve the issue if you query is declared this way: >=20 > Select query =3D new SelectQuery... >=20 > 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, 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. >=20 > If we stick with the overloading using SelectQuery we could still = add > other overloads for specific types as well, it just gets repetitious. >=20 >=20 > On Mon, Dec 10, 2012 at 4:09 AM, Andrus Adamchik = wrote: >=20 >> 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: >>=20 >> interface Select >>=20 >> SelectQuery extends QualifiedQuery implements Select >>=20 >> List performQuery(Select query) >>=20 >> Then we can reuse the same ObjectContext method for other queries we = might >> invent. >>=20 >> Andrus >>=20 >>=20 >> On Dec 10, 2012, at 9:05 AM, John Huss (JIRA) = wrote: >>> [ >> = https://issues.apache.org/jira/browse/CAY-1294?page=3Dcom.atlassian.jira.p= lugin.system.issuetabpanels:all-tabpanel] >>>=20 >>> John Huss updated CAY-1294: >>> --------------------------- >>>=20 >>> Attachment: >> 0002-Minimize-compiler-warnings-about-missing-type-parame.patch >>>=20 >> 0001-Add-type-parameter-to-SelectQuery-to-indicate-query-.patch >>>=20 >>> 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 that returns List. >>>=20 >>> List performQuery(SelectQuery query); >>>=20 >>> The 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 and you avoid the >> compiler warning. This seems like a simple win - any objections? >>>=20 >>> 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.class, null), which feels very tedious. = So if >> you prefer you can call SelectQuery.from(Artist.class, null) instead = and it >> will infer List as the query result type. >>>=20 >>> public static SelectQuery from(Class rootClass, Expression >> qualifier); >>>=20 >>>> Generify query >>>> -------------- >>>>=20 >>>> 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 >>>>=20 >>>> Attachments: >> 0001-Add-type-parameter-to-SelectQuery-to-indicate-query-.patch, >> 0002-Minimize-compiler-warnings-about-missing-type-parame.patch >>>>=20 >>>>=20 >>>> Although most of the generics work has been completed for 3.0, = 'query' >> is still largely untouched. =46rom 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 . >>>=20 >>> -- >>> 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 >>>=20 >>=20 >>=20