From dev-return-6388-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Sep 14 05:23:18 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 50293 invoked from network); 14 Sep 2009 05:23:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Sep 2009 05:23:18 -0000 Received: (qmail 42916 invoked by uid 500); 14 Sep 2009 05:23:18 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 42813 invoked by uid 500); 14 Sep 2009 05:23:17 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 42803 invoked by uid 99); 14 Sep 2009 05:23:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Sep 2009 05:23:17 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.212.171 as permitted sender) Received: from [209.85.212.171] (HELO mail-vw0-f171.google.com) (209.85.212.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Sep 2009 05:23:06 +0000 Received: by vws1 with SMTP id 1so1647177vws.13 for ; Sun, 13 Sep 2009 22:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=U0ADEO0CJ426lncW+eH2wFu5GLjAjfL5B57EoIadDQA=; b=dZ5+n0jw+rn0C6O+FHZf5n8lvaIFpbjQA7AnEV4WHXPXk/qvzA4/Qlzos3SH/9Ir15 fmHgXYg0IS4KsmCBjdB9Pi/n7OaQ9JTr/9uWTlcEAnzZE0DHA/Qb9Pi7B+6gdWPaHttT wxZdkeBS2kAkbOU1W6eSVgf5JX0pKny0VwLvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=HMkF8n3rP/ihuaZxF0cMuFTrBogfcmYEbjRDBpxCGGeayKX6/DIaKzqgObDJ4HCGlP Mzhf3lrBIhfAvo53iLsZ5DBTlCoJ9PJjLO2sEnOm2TO3aa8+Z8faq2EWz54VYROq6YxA RcvrweXrlWfGCgSaXvzfdRRLCresoTp5QeQ1E= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.220.89.93 with SMTP id d29mr7583291vcm.26.1252905765697; Sun, 13 Sep 2009 22:22:45 -0700 (PDT) In-Reply-To: References: <20090910165815.GA23715@uk.tiscali.com> Date: Sun, 13 Sep 2009 22:22:45 -0700 X-Google-Sender-Auth: c217954c18f54c77 Message-ID: Subject: Re: Inconsistencies (?) when querying reduce views From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Sep 10, 2009 at 10:26 AM, Paul Davis wrote: > On Thu, Sep 10, 2009 at 12:58 PM, Brian Candler wrote: >> I've noticed a couple of possible inconsistences in querying a reduce view, >> which I thought I'd raise here rather than in JIRA for now. >> >> I am comparing querying a reduce view with a single key in the URL, versus >> querying it with a single key in a POST fetch. That is, >> >> GET /db/_design/ddoc/_view/vname?key=%22abc%22 >> >> vs. >> >> POST /db/_design/ddoc/_view/vname >> {keys:["abc"]} >> >> (1) If you perform a multi-key fetch as above, it is refused with >> "query_parse_error", "multi-key fetchs for reduce view must include >> `group=true`", until you add ?group=true to the URL. However you do not need >> to do this for the single-key case. >> >> (2) In the single key case, you get "key":null in the response row, whereas >> in the multi-key fetch you get "key":"abc" or whatever the actual key was. >> Apart from this, both give a response in the same format, i.e. >> >> {"rows":[ >> {"key":null,"value":123} >> ]} >> >> Any comments on this? I would have thought that the two should work in the >> same way. >> >> Regards, >> >> Brian. >> > > That is a bit of an awkward inconsistency. > > What's going on is that ?key="foo" is internally equivalent to > ?startkey="foo"&endkey="bar" When doing reduces with a start/end key > its calculating the single reduce value between those values. > > Using the multi-key fetch we're trying to pull back a row for a given > key, if you don't have a ?group=true then there are no keys to look > for. > > Paul Davis > I wouldn't mind seeing a JSON definition for queries, so that all view queries (not just multi-key) could be posted to the view (and with temp views). If we had something like this: { "limit":10, "startkey":[1,2,"foo], "descending":true } we could allow POSTing arrays of these, for a series of view queries in on request. I know some people who really want to see this, writing this could make you a hero. This would clean up the key="foo" vs keys : ["foo"] disparity, and give a bunch more flexibility about multi-range queries. Chris -- Chris Anderson http://jchrisa.net http://couch.io