Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.223.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=qfLmse04mVfjlHyZbmAIoEa/cGyHmxwTyNbOy5n+r+RtD//ArsqS3kwHBWmCqzT7YJ
         Ql+4qSHcboKze8OgEWTaPL0DSqEmaG2/euHJmnshSwj2h4hjz56n1uHe8CtFWXk19Q2i
         CVN1KR+Gx2IKSDelCIlq9fMla7qTr4wKMokAs=
MIME-Version: 1.0
In-Reply-To: <e8d26ac40910270942g38b6340bv2a5917ac0777c3e6@mail.gmail.com>
References: <8098243e0910270750n52f9a2dcma2d1592daaa9986f@mail.gmail.com>
	<03E7FF46-E9A4-4AF7-8CEE-7283F23E0EB3@apache.org>
 <e8d26ac40910270837g20d1ffcdq712c76fe305fab35@mail.gmail.com>
	<e2111bbb0910270849v18cde1f8o7a392eb997d2bbfa@mail.gmail.com>
	<e8d26ac40910270942g38b6340bv2a5917ac0777c3e6@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 27 Oct 2009 13:46:44 -0400
Message-ID: <e2111bbb0910271046ud53931xc984febfb964003f@mail.gmail.com>
Subject: Re: multiple range queries via POST?
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Indeed. Good catch.

On Tue, Oct 27, 2009 at 12:42 PM, Adam Wolff <awolff@gmail.com> wrote:
> makes sense. should that be "ranges"?
> A
>
> On Tue, Oct 27, 2009 at 8:49 AM, Paul Davis <paul.joseph.davis@gmail.com>=
wrote:
>
>> I'd rather see something like:
>>
>> {keys: [k1, k2, k3]}
>>
>> or
>>
>> {range: [query_params_1, query_params_2]}
>>
>> with
>>
>> query_params_1 =3D {startkey: k1, endkey: k2} etc etc
>>
>> With ranges and keys being mutually exclusive
>>
>> Paul Davis
>>
>> On Tue, Oct 27, 2009 at 11:37 AM, Adam Wolff <awolff@gmail.com> wrote:
>> > 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 <kocolosk@apache.org>
>> wrote:
>> >
>> >> On Oct 27, 2009, at 10:50 AM, Alex P wrote:
>> >>
>> >> =A0i know this is currently unsupported (and may be more of a questio=
n 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) {
>> >>> =A0if (doc.docType !=3D 'message') return;
>> >>>
>> >>> =A0emit(doc.owner, null);
>> >>> }
>> >>>
>> >>> if i wanted to pull back all messages for users foo and bar, i'd sim=
ply
>> do
>> >>> a
>> >>> POST path/to/couch keys =3D ['foo', 'bar']. now let's make this data=
 come
>> >>> back
>> >>> sorted by create date:
>> >>>
>> >>> function (doc) {
>> >>> =A0if (doc.docType !=3D 'message') return;
>> >>>
>> >>> =A0emit([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=3D['foo']&endKey=3D['foo', 'a'=
]. this
>> >>> works, but it now means that if i want all messages pertaining to bo=
th
>> 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 wo=
uld
>> be
>> >>> with having to merge overlapping ranges, but i still would like some=
one
>> >>> else
>> >>> to weigh in on this
>> >>>
>> >>>
>> >>> thanks,
>> >>> alex.
>> >>>
>> >>
>> >> Hi Alex, internally, multiple keys are actually just a special case o=
f
>> >> multiple ranges. =A0So that part is easy. =A0We would want to be clea=
r 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
>> >>
>> >>
>> >
>>
>