Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 50634 invoked from network); 27 Oct 2009 15:38:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Oct 2009 15:38:22 -0000 Received: (qmail 74134 invoked by uid 500); 27 Oct 2009 15:38:21 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 74085 invoked by uid 500); 27 Oct 2009 15:38:21 -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 74075 invoked by uid 99); 27 Oct 2009 15:38:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Oct 2009 15:38:21 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of awolff@gmail.com designates 209.85.222.193 as permitted sender) Received: from [209.85.222.193] (HELO mail-pz0-f193.google.com) (209.85.222.193) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Oct 2009 15:38:18 +0000 Received: by pzk31 with SMTP id 31so194177pzk.28 for ; Tue, 27 Oct 2009 08:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=jbju5RQa1YamBbUlZtW3CCtInUIevb8/REPFMVlKoHs=; b=Vfy4x/4OR9PTRZ+WKB1E+p8b1kb+QaczKoo65orkqbA3Jrkh0IQYkkU8ASYe/+NV43 3F1gLI4hCoLwvNjYhCqqU7o+ivcmJXTVr5tt4qbzsOaG1vxNk2O+GqTb3ng75JF3IzTj 8Gr0dyasmWTO+VYXskcOkQMxUOnFLz08v/u+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ke6RKVgtiv5fCubJgnx7AkIxmufGjov9ZwQFQ4t9TB6xdw1R0Xhwz0YIfmiO0TZNRs BXM5bUIY/pwa7w6Vg+BD53NdBoJi2cRIDKkzcg+OyDXah8WGX9OGnege2EbSKGQDEk8w m5PGeVDWDOaYdEa+tHWLSEzZrEPMMPdR597js= MIME-Version: 1.0 Received: by 10.140.134.9 with SMTP id h9mr2104143rvd.43.1256657878407; Tue, 27 Oct 2009 08:37:58 -0700 (PDT) In-Reply-To: <03E7FF46-E9A4-4AF7-8CEE-7283F23E0EB3@apache.org> References: <8098243e0910270750n52f9a2dcma2d1592daaa9986f@mail.gmail.com> <03E7FF46-E9A4-4AF7-8CEE-7283F23E0EB3@apache.org> Date: Tue, 27 Oct 2009 08:37:58 -0700 Message-ID: Subject: Re: multiple range queries via POST? From: Adam Wolff To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=000e0cd2be62725a0b0476ec76a2 --000e0cd2be62725a0b0476ec76a2 Content-Type: text/plain; charset=ISO-8859-1 We could really use this feature too. Right now, we do this: post("/path_to_view/", {keys : keys}); For this feature, maybe the syntax could be post("/path_to_view/", {keys : [{start:[k1, null], end:[k1, {}]}, {start:[k2, null], end:[k2, {}]} }); A On Tue, Oct 27, 2009 at 7:55 AM, Adam Kocoloski wrote: > On Oct 27, 2009, at 10:50 AM, Alex P wrote: > > i know this is currently unsupported (and may be more of a question for >> the >> dev list), but is there a technical reason while multi-range queries can't >> be submitted to couch (slight ah-hah moment at the end)? >> >> the specific problem i'm trying to address is this: >> >> suppose i have a message document, and a corresponding map function: >> >> function (doc) { >> if (doc.docType != 'message') return; >> >> emit(doc.owner, null); >> } >> >> if i wanted to pull back all messages for users foo and bar, i'd simply do >> a >> POST path/to/couch keys = ['foo', 'bar']. now let's make this data come >> back >> sorted by create date: >> >> function (doc) { >> if (doc.docType != 'message') return; >> >> emit([doc.owner, doc.createDate], null); >> } >> >> also cool, but now, to retrieve all messages pertaining to a single user, >> i >> need to do GET path/to/couch startKey=['foo']&endKey=['foo', 'a']. this >> works, but it now means that if i want all messages pertaining to both foo >> and bar, i need to run two separate queries. >> >> as i'm writing this, i think i'm starting to see that the problem would be >> with having to merge overlapping ranges, but i still would like someone >> else >> to weigh in on this >> >> >> thanks, >> alex. >> > > Hi Alex, internally, multiple keys are actually just a special case of > multiple ranges. So that part is easy. We would want to be clear about how > we handle overlapping ranges, but it's not that hard of a problem really. > > I wonder what the HTTP call for this should look like? > > Adam > > --000e0cd2be62725a0b0476ec76a2--