couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ryah dahl">
Subject Re: [PATCH] Views: Multiple keys
Date Wed, 23 Jul 2008 15:05:05 GMT
Although no one uses it, GET (and even HEAD) requests are not
forbidden from having bodies. (I think.)

On Wed, Jul 23, 2008 at 3:29 PM, Paul Bonser <> wrote:
> On 7/23/08, Matt Goodall <> wrote:
>> Hi,
>>  I think this functionality would be hugely beneficial in CouchDB but
>>  POST'ing to a view seems so very, very wrong to me.
> I originally suggested doing it as a key_list GET parameter, but
> decided against it after a comment from Damien "The only thing is I
> don't think a GET with all the keys are URL args is the way to go as
> it can get really long and cause problems with proxies and HTTP libs,
> a POST with the lookup keys as the body is probably better."
>>  How about using a GET on the view but support multiple 'key' args, one
>>  for each of the view rows to return, e.g.
>>     GET /somedb/_views/somedoc/someview?key=1&key=2&key=3
> The problem with doing it that way is that some people will want to
> give a list of hundreds or thousands of keys, and and that point the
> query would be too long and start breaking in all sorts of different
> situations.
>>  The 'key' arg(s) already seem to take precedence over startkey,
>>  endkey, etc and the view always returns a 'rows' list so it /should/
>>  be a matter of iterating the JSON values sent as 'key' instead of
>>  parsing the JSON structure sent as POST content.
> The implementation using GET would be just about as simple as the one
> I sent, though some changes to parse_view_query and the
> view_query_args structure would be necessary.
>>  I guess there's the possibility of hitting max URL length problems on
>>  some browsers/servers but that can be worked around by requesting the
>>  view in batches of keys.
> Once again, if we did that, we'd be right back to the problem of doing
> multiple requests, which is exactly what this new functionality is
> trying to avoid.
> --
> Paul Bonser

View raw message