From user-return-7967-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Dec 10 17:25:05 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 75046 invoked from network); 10 Dec 2009 17:25:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Dec 2009 17:25:05 -0000 Received: (qmail 94784 invoked by uid 500); 10 Dec 2009 17:25:03 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 94707 invoked by uid 500); 10 Dec 2009 17:25:03 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 94697 invoked by uid 99); 10 Dec 2009 17:25:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 17:25:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=NORMAL_HTTP_TO_IP,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.160.56 as permitted sender) Received: from [209.85.160.56] (HELO mail-pw0-f56.google.com) (209.85.160.56) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 17:24:53 +0000 Received: by pwi19 with SMTP id 19so38789pwi.35 for ; Thu, 10 Dec 2009 09:24:32 -0800 (PST) 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:content-transfer-encoding; bh=sXE2zngcO3GQIk1oUkZMgyTCkOC7YLC6t3DK2sZ0vKs=; b=eDCFOzjjCBK/J2cIRhiNaZErgAatP3FNS6Js/mhisMtNYJMiyAAJQXpRFJLGCei4b+ 4kXFCWagKvsGfnIpEdXp9a8v9hUyz9LsNwrOv17ojTpz/a1SLFH4shUpaF0ms58ReAEi uOkWel1ln7fBka/JBGj/QEzVz6ZvBtBkhan2M= 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 :content-transfer-encoding; b=crSFy1gEYu7lJquymZREQfesfc21sZiudOli3pD/V3sJq8kEdTkEwLzJJuhvvQKkA0 spDASLkoj5WWMJWQkPFxes3TiUK7PLWiJDr8/k1mXIpyMDmLwI9cPACvOytGuZDwudUX CrNfZJVVrfEAXWxMoVm0WDXKsJB74voW8+BM8= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.142.55.20 with SMTP id d20mr133967wfa.37.1260465871980; Thu, 10 Dec 2009 09:24:31 -0800 (PST) In-Reply-To: References: <04C82F94-CF83-45D9-B599-47A8DD7C0501@gmail.com> Date: Thu, 10 Dec 2009 09:24:31 -0800 X-Google-Sender-Auth: fee9c046cfaf3649 Message-ID: Subject: Re: No safe way to query and not ever reduce a view. From: Chris Anderson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Dec 10, 2009 at 7:51 AM, Paul Davis w= rote: > On Thu, Dec 10, 2009 at 10:27 AM, Luke Sneeringer > wrote: >> Greetings, >> So I'm in a situation here, and perhaps I'm missing something obvious. >> >> I have four views. They work fine. Two of them have reduce functions, an= d two of them don't. On views with a reduce function, CouchDB sends reduced= replies unless you specifically tell it not to. Anyway, in this particular= instance, I want to query a view that may or may not have a reduce functio= n, but I want the non-reduced results. >> >> This seems simple enough...just add ?reduce=3Dfalse. However, if you sen= d ?reduce=3Dfalse to a map-only view, you get an error from CouchDB. I also= can find no way to ask if a view is a map-view or a map-reduce-view. In ot= her words, if I have a view that may or may not have a reduce function, the= only way I can see to get non-reduced results is to send a request with ?r= educe=3Dfalse, catch the exception that's raised if it was a map-only view,= and send the query again without ?reduce=3Dfalse. >> > > I've never considered the scenario where the view was being accessed > without knowledge of what view it was. Which seems odd, but if its > popping up on the ML, then there's probably quite a few other people > trying it as well. > >> This feels quite clunky to me and not at all relaxing. I understand the = strict error checking, but I suppose it seems there should either be a sali= ent way to see which request form I should use, or there should be a reques= t form that works in both cases? If I don't want reduced results, after all= , it shouldn't matter if I have a reduce function. > > Chris Anderson yelled at me about that as well. When I was writing > that parsing I was attempting to fix a very common problem where > people were trying to use a query parameter and then failing to figure > out why CouchDB wasn't working as expected. I don't remember the exact > parameter, but it was the equivalent of "reduce=3Dfalse" with no reduce > function, and then the ML and IRC got filled with questions of > "There's no difference between reduce=3Dfalse and not specifying it! > What's up with that?" I think we should just stop validating the query parameters so strictly. This would be a simple first patch for someone interested. > > So after awhile I fixed it and now the URL processing tries to detect > as many errors as possible and complain loudly. > >> Which brings me to the mailing list. Am I missing something? I looked in= the manual, and found nothing. Is this in CouchDB? If so, how do I do it? >> > > Nothing yet. Though as part of the ensuing discussion on whether this > exact scenario should be an error or not I made the suggestion that > maybe our views should use two URL handlers. Something like: > > http://127.0.0.1:5984/db_name/_design/foo/_map/bar > http://127.0.0.1:5984/db_name/_design/foo/_reduce/bar > > But I got yelled at for suggesting API changes. > > HTH, > Paul Davis > --=20 Chris Anderson http://jchrisa.net http://couch.io