incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex P <apede...@kolosy.com>
Subject Re: multiple range queries via POST?
Date Tue, 27 Oct 2009 15:01:06 GMT
good to hear. re: http call - well it should be consistent with the keys
call, shouldn't it? so a POST with startKey[s] and an endKey[s] arguments?

out of curiousity - when a view subset is returned, is it 'streamed' out? or
is the entire dataset prefetched and then returned?

i could see overlapping ranges being simple to solve mathematically, but
posing either seek or memory issues (reading the two ranges concurrently vs.
pre-fetching both and doing a merge)

On Tue, Oct 27, 2009 at 9:55 AM, Adam Kocoloski <kocolosk@apache.org> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message