Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 38192 invoked from network); 28 Oct 2006 21:07:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Oct 2006 21:07:13 -0000 Received: (qmail 5592 invoked by uid 500); 28 Oct 2006 21:07:24 -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 5581 invoked by uid 99); 28 Oct 2006 21:07:24 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 14:07:24 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.148.213.132] (HELO smtp.mailix.net) (216.148.213.132) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 14:07:10 -0700 Received: from [192.168.8.8] (helo=localhost) by smtp.mailix.net with asmtp (Exim 4.24-BE) id 1GdvNz-0006a1-SK for jdo-dev@db.apache.org; Sat, 28 Oct 2006 14:06:35 -0700 Received: from 117.116-240-81.adsl-dyn.isp.belgacom.be (117.116-240-81.adsl-dyn.isp.belgacom.be [81.240.116.117]) by webmail.jpox.org (IMP) with HTTP for ; Sat, 28 Oct 2006 14:06:44 -0700 Message-ID: <1162069604.4543c664e653e@webmail.jpox.org> Date: Sat, 28 Oct 2006 14:06:44 -0700 From: Erik Bengtson To: jdo-dev@db.apache.org References: <4542764E.8020105@spree.de> <24878E87-227A-4A45-9217-3F6E56609417@SUN.com> <1162045186.454367021f005@webmail.jpox.org> In-Reply-To: MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 81.240.116.117 X-SA-Exim-Mail-From: erik@jpox.org Subject: Re: JDOQL query problems (JPOX issues?) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Version: 3.1 (built Thu Oct 23 13:26:47 PDT 2003) X-SA-Exim-Scanned: No; Unknown failure X-uvscan-result: clean (1GdvNz-0006a1-SK) X-Virus-Checked: Checked by ClamAV on apache.org Craig, I understand that variables of PC get bound to a set of pc type, but strings... What is it bound to? rgds Quoting Craig L Russell : > Hi Erik, > > On Oct 28, 2006, at 7:19 AM, Erik Bengtson wrote: > > > Michael, > > > > I was reading Craig comments and noted that "str" is an unbound > > variable > > The variable "str" is bound by the filter q.setFilter > ("this.stringCol.contains(str)"). > > Craig > > a parameter, and now I think the query is invalid since there is no > > value for > > str. > > > > Unbound variables are not null values. > > > > Quoting Craig L Russell : > > > >> Hi Michael, > >> > >> From the spec, > >> > >> The candidate tuples > >> are the cartesian product of the candidate class and all variables > >> used in the result. The re- > >> sult tuples are the tuples of the candidate class and all variables > >> used in the result that sat- > >> isfy the filter. The result is the collection of result expressions > >> projected from the result > >> tuples. > >> > >> > >> On Oct 27, 2006, at 2:12 PM, Michael Bouschen wrote: > >> > >>> Hi, > >>> > >>> I'm having problems running JDOQL queries that group by a variable. > >>> I think the queries below are valid, but I would like to double > >>> check this. If you agree that the queries are valid JDOQL, I will > >>> check the TCK to add these queries to existing TCK tests or add new > >>> test cases. I tried the queries with JPOX version 1.1.3 and with > >>> the nightly build from Oct 27 (no difference). I will send a test > >>> case to reproduce the problem to Erik and Andy, since I cannot > >>> attach archives here. > >>> > >>> The class model is simple: pc class A has a field stringCol which > >>> is a collection of strings and another field bCol which is a > >>> collection of instances of class B. > >>> > >>> The following query groups the class A instances by the strings in > >>> their string collection: > >>> Query q = pm.newQuery(A.class); > >>> q.declareVariables("java.lang.String str"); > >>> q.setFilter("this.stringCol.contains(str)"); > >>> q.setGrouping("str"); > >>> q.setResult("str"); > >> > >> The cartesian product of the candidate class and all variables is a > >> the cartesian product of all A instances and all strings contained in > >> any stringCol. The result tuples consist of tuples of (A, String) > >> where the elements of stringCol are projected and associated with the > >> instances of A whence they came. The result comes from grouping and > >> projecting the String from the result tuple. So, > >> > >> This query should collect all of the unique strings in all instances > >> of A stringCol. The result is a List. I don't know offhand > >> how the implementation can do this trick (returning a List