Indeed. Good catch.
On Tue, Oct 27, 2009 at 12:42 PM, Adam Wolff <[email protected]> wrote: > makes sense. should that be "ranges"? > A > > On Tue, Oct 27, 2009 at 8:49 AM, Paul Davis > <[email protected]>wrote: > >> I'd rather see something like: >> >> {keys: [k1, k2, k3]} >> >> or >> >> {range: [query_params_1, query_params_2]} >> >> with >> >> query_params_1 = {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 <[email protected]> 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 <[email protected]> >> 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 >> >> >> >> >> > >> >
