Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 27486 invoked from network); 15 Feb 2006 18:39:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Feb 2006 18:39:55 -0000 Received: (qmail 7499 invoked by uid 500); 15 Feb 2006 18:39:54 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 7488 invoked by uid 99); 15 Feb 2006 18:39:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2006 10:39:54 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [69.20.13.148] (HELO utopia14.tralfamadore.com) (69.20.13.148) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2006 10:39:53 -0800 Received: from [10.51.15.65] ([62.189.209.116]) (authenticated) by utopia14.tralfamadore.com (8.11.6/8.11.6) with ESMTP id k1FIdVo21748; Wed, 15 Feb 2006 13:39:31 -0500 Message-ID: <43F3755D.1050602@tralfamadore.com> Date: Wed, 15 Feb 2006 18:39:25 +0000 From: Wes Biggs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jdo-dev@db.apache.org, JDO Expert Group Subject: Re: Negative VOTE Issue 159: Restrict projections to single-valued fields References: <20060215102041.61537.qmail@web51003.mail.yahoo.com> <1140022661.43f35d85bad6b@webmail.jpox.org> In-Reply-To: <1140022661.43f35d85bad6b@webmail.jpox.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I still contend that "distinct" does not imply the .equals() operator, and thus the answer would be Collection1 [emp1,emp2,emp3] Collection2 [emp1,emp2,emp3] Where Collection1 != Collection2 even though Collection1.equals(Collection2). Consider an employee database with two men named John Smith and datastore identity in use. I would expect "select distinct this from Employee where name=='John Smith'" to return 2 results. Wes erik@jpox.org wrote: >Hi Bin, > > > >>or result 2: >>[emp1,emp2,emp3] >> >> > >The result would be 2 IMO according to what collection.equals contract says. > >For distinct queries, The easiest way is to evaluate it in memory. Of course, >optimal solutions may still apply. > >For non distinct queries, that's very simple and collections can be lazy loaded. > >Quoting Bin Sun : > > > >>Hi, Erik! >> >> I mean which would be the result? >> >>result 1: >>[emp1,emp2,emp3] >>[emp1,emp2,emp3] >> >>or result 2: >>[emp1,emp2,emp3] >> >>? >> >> If SQL 'distinct' used, we'll get result 1, I >>guess. But as 'distinct' defined, the result should be >>result 2, like a 'distinct name' query. >> >>--- erik@jpox.org wrote: >> >> >> >>>Bin, >>> >>>Using distinct keyword the most database independent >>>would be doing that in >>>memory, but for some databases you can create stored >>>procedures or UDFs. >>> >>>Regards, >>> >>>Quoting Bin Sun : >>> >>> >>> >>>>Hi, erik! >>>> >>>> I'm curious. If we have two departments: >>>>dept1 has employees: emp1, emp2, emp3 >>>>dept2 has employees: emp1, emp2, emp3 >>>> >>>>(assume 'employees' is not a many-to-one relation) >>>> >>>>What will be the result of: (one or two result >>>>row(s)?) >>>>select distinct employees from Department >>>> >>>>and what SQL would be generated? >>>> >>>>--- erik@jpox.org wrote: >>>> >>>> >>>> >>>>>-1. I vote for non-portable. It's simple to >>>>>implement. >>>>> >>>>>Quoting Craig L Russell : >>>>> >>>>> >>>>> >>>>>>Javadogs, >>>>>> >>>>>>If none of the implementations supports >>>>>> >>>>>> >>>>>projections of collections or >>>>> >>>>> >>>>>>maps, we can simply disallow it. If some do >>>>>> >>>>>> >>>>>support it, we can say >>>>> >>>>> >>>>>>it's not portable. >>>>>> >>>>>>For now, I'll propose disallowing it, and if >>>>>> >>>>>> >>>there >>> >>> >>>>>are >>>>> >>>>> >>>>>>implementations out there we can change to >>>>>> >>>>>> >>>>>non-portable. >>>>> >>>>> >>>>>> >>>>>>Specifying the Result of a Query (Projections, >>>>>> >>>>>> >>>>>Aggregates) >>>>> >>>>> >>>>>>The application might want to get results from >>>>>> >>>>>> >>>a >>> >>> >>>>>query that are not >>>>> >>>>> >>>>>>instances of the candidate class. The results >>>>>> >>>>>> >>>>>might be single-valued >>>>> >>>>> >>>>>>fields of persistent instances, instances of >>>>>> >>>>>> >>>>>classes other than the >>>>> >>>>> >>>>>>candidate class, or aggregates of >>>>>> >>>>>> >>>single-valued >>> >>> >>>>>fields. >>>>> >>>>> >>>>>> >>>>>> >>>>>>Craig >>>>>> >>>>>>On Feb 13, 2006, at 8:58 PM, Craig L Russell >>>>>> >>>>>> >>>>>wrote: >>>>> >>>>> >>>>>>>Hi Bin, >>>>>>> >>>>>>>I think it's confusing to project a >>>>>>> >>>>>>> >>>collection >>> >>> >>>>>or map in a query. >>>>> >>>>> >>>>>>>The reason is that if there is a variable >>>>>>> >>>>>>> >>>that >>> >>> >>>>>derives from the >>>>> >>>>> >>>>>>>same field as is being projected, the user >>>>>>> >>>>>>> >>>might >>> >>> >>>>>think that the >>>>> >>>>> >>>>>>>field will be subject to the same >>>>>>> >>>>>>> >>>constraints as >>> >>> >>>>>the query, but >>>>> >>>>> >>>>>>>this would be wrong. >>>>>>> >>>>>>>I'd rather we restrict projections of >>>>>>> >>>>>>> >>>collection >>> >>> >>>>>and map in >>>>> >>>>> >>>>>>>queries. We can always add it later once we >>>>>>> >>>>>>> >>>>>think more about >>>>> >>>>> >>>>>>>whether it makes sense and has a strong >>>>>>> >>>>>>> >>>>>justification. >>>>> >>>>> >>>>>>>What can the user not do today if we >>>>>>> >>>>>>> >>>restrict >>> >>> >>>>>projection of >>>>> >>>>> >>>>>>>collections and maps? If the user really >>>>>>> >>>>>>> >>>wants >>> >>> >>>>>to navigate to the >>>>> >>>>> >>>>>>>collection or map field, then just project >>>>>>> >>>>>>> >>>the >>> >>> >>>>>instance and >>>>> >>>>> >>>>>>>navigate to the fields of interest. >>>>>>> >>>>>>>Craig >>>>>>> >>>>>>>On Feb 13, 2006, at 6:27 PM, Bin Sun wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi, all! >>>>>>>> >>>>>>>> Did anyone notice this? >>>>>>>> >>>>>>>>--- Bin Sun wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi! >>>>>>>>> >>>>>>>>> I have more concern about Collection >>>>>>>>> >>>>>>>>> >>>and >>> >>> >>>>>Map >>>>> >>>>> >>>>>>>>>projection: is this query easy to >>>>>>>>> >>>>>>>>> >>>implement? >>> >>> >>>>>>>>>select distinct employees from Department >>>>>>>>> >>>>>>>>> >>>>>where ... >>>>> >>>>> >>>>>>>>>At least I don't know how a SQL datastore >>>>>>>>> >>>>>>>>> >>>>>could >>>>> >>>>> >>>>>>>>>compare the collections one another. >>>>>>>>> >>>>>>>>> So, maybe we should discribe more on >>>>>>>>> >>>>>>>>> >>>>>Collection >>>>> >>>>> >>>>>>>>>and Map projection, or simply specify that >>>>>>>>> >>>>>>>>> >>>>>their >>>>> >>>>> >>>>>>>>>distinction is the same as their owner >>>>>>>>> >>>>>>>>> >>>>>objects, >>>>> >>>>> >>>>>>>>>dispite whether they equal one another. >>>>>>>>> >>>>>>>>>--- erik@jpox.org wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Thanks for the comments, I agree with you >>>>>>>>>> >>>>>>>>>> >>>>>all. >>>>> >>>>> >>>>>>>>>>Regards, >>>>>>>>>> >>>>>>>>>>Quoting Michael Bouschen >>>>>>>>>> >>>>>>>>>> >>>: >>> >>> >>>>>>>>>>>Hi, >>>>>>>>>>> >>>>>>>>>>>I have the same understanding of the >>>>>>>>>>> >>>>>>>>>>> >>>>>semantics >>>>> >>>>> >>>>>>>>>of >>>>>>>>> >>>>>>>>> >>>>>>>>>>projections of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>collection and map fields as Wes and Bin >>>>>>>>>>> >>>>>>>>>>> >>>>>Sun. >>>>> >>>>> >>>>>>>>>The >>>>>>>>> >>>>>>>>> >>>>>>>>>>query would return the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>collections or maps as single cells, so >>>>>>>>>>> >>>>>>>>>>> >>>the >>> >>> >>>>>>>>>query >>>>>>>>> >>>>>>>>> >>>>>>>>>>result would be a list >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>of collections or maps. I also agree >>>>>>>>>>> >>>>>>>>>>> >>>that >>> >>> >>>>>>>>>support >>>>>>>>> >>>>>>>>> >>>>>>>>>>for projections of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>collection and map fields does not add >>>>>>>>>>> >>>>>>>>>>> >>>much >>> >>> >>>>>>>>>value, >>>>>>>>> >>>>>>>>> >>>>>>>>>>but AFAIK the current >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>spec allows this. >>>>>>>>>>> >>>>>>>>>>>I think the shape of the query result is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>different >>>>>>>>> >>>>>>>>> >>>>>>>>>>whether projecting a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>collection field or including a variable >>>>>>>>>>> >>>>>>>>>>> >>>in >>> >>> >>>>>the >>>>> >>>>> >>>>>>>>>>result that iterates the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>collection: >>>>>>>>>>>(1) SELECT employees FROM Department >>>>>>>>>>>(2) SELECT e FROM Department WHERE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>employees.contains(e) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>The first query returns a list of >>>>>>>>>>> >>>>>>>>>>> >>>>>collections of >>>>> >>>>> >>>>>>>>>>employees, so for each >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>department it returns the department's >>>>>>>>>>> >>>>>>>>>>> >>>>>employee >>>>> >>>>> >>>>>>>>>>collection. Query (2) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>returns a list of employees, where each >>>>>>>>>>> >>>>>>>>>>> >>>>>returned >>>>> >>>>> >>>>>>>>>>employee is included in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> an employee collection of at least one >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>department. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Given the above is correct, JDOQL would >>>>>>>>>>> >>>>>>>>>>> >>>>>never >>>>> >>>>> >>>>>>>>>>return Map.Entry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>instances. Either the query projects the >>>>>>>>>>> >>>>>>>>>>> >>>>>entire >>>>> >>>>> >>>>>>>>>>map or it iterates the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>map using containsKey or containsValue, >>>>>>>>>>> >>>>>>>>>>> >>>but >>> >>> >>>>>>>>>there >>>>>>>>> >>>>>>>>> >>>>>>>>>>is no contains for maps. >>>>>>>>>> >>>>>>>>>> >>=== message truncated === >> >> >>__________________________________________________ >>Do You Yahoo!? >>Tired of spam? Yahoo! Mail has the best spam protection around >>http://mail.yahoo.com >> >> >> > > > >