Re: [PATCH] Views: Multiple keys

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 
<misterpib-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote:
> On 7/23/08, Matt Goodall 
> <matt.goodall-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> 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
> http://blog.paulbonser.com
>