On Tue, Jan 11, 2011 at 10:07 PM, Adam Kocoloski <[email protected]> wrote:
> Hi Alex, I agree, it's awkward.  Note that CouchDB already supports POSTing 
> to a view to select several individual keys.  If I recall correctly that 
> decision came down to the fact that
>
> a) servers put limits on the length of a URL (in mochiweb at the time it was 
> 8KB)
> b) GET requests with bodies are not well-supported
>
> so if a user wanted to select hundreds of keys from a view a POST seemed like 
> the path of least resistance.  This multi-query support wouldn't introduce 
> any new weirdness in that respect.  I'm open to alternatives, though I think 
> the POST option would probably still go forward because it's so similar to 
> existing features.

Adam,

I do agree that all these limitations do exist in various
environments, but I'd say what is important for this discussion is if
they exist in the CouchDB environment.

What I actually mean by this is:

1. will anyone try to submit an 8k long GET from a browser? I highly
doubt that and I assume this scenario is most of the time happening
with a programmed client

2. is there an HTTP spec restriction related to the length of URIs? As
far as I know there isn't one.

3. is there an HTTP spec restriction related to GET body? As far as I
know there isn't one here either.

So, based on these I'd say that if CouchDB is able to handle long URIs
GETs and/or support GET bodies problem is solved.

:- alex

PS: I'm "lying" a bit here because there's also the problem of proxies
that we would need to look at :-).


Best,
>
> Adam
>
> On Jan 11, 2011, at 1:02 PM, Alexandru Popescu ☀ wrote:
>
>> While the feature sounds pretty useful there is something that I
>> couldn't stop thinking: a POST for a view?
>>
>> I know that sounds purist but on the other hand one of the highest
>> praised characteristics of CouchDB is its HTTPness. On the other hand
>> I'm not sure I see all the angles of this feature to come up with a
>> better proposal. Maybe we could discuss it on #irc and see if there're
>> better solutions (at least for the general cases).
>>
>> :- alex
>>
>>
>> On Tue, Jan 11, 2011 at 5:21 PM, Adam Kocoloski <[email protected]> wrote:
>>> On Jan 11, 2011, at 9:58 AM, Chad George wrote:
>>>
>>>> Is there any work being done on getting multiple views in a single HTTP
>>>> request. I'm thinking of something similar to the multiple doc API.
>>>>
>>>> I just finished my first significant webapp with couchdb and one of the
>>>> things that was a little annoying with a javascript client was all the
>>>> nested async callbacks required to get all the data required for a
>>>> particular function to process.
>>>>
>>>> Sometimes this was 3 or 4 nested view lookups, and gracefully handling
>>>> errors is difficult. It would be much easier if I could pack them into a
>>>> single async call to couchdb then handle errors or success just once.
>>>>
>>>> This isn't really a critical feature since it can be done with multiple
>>>> requests, I'm not even sure it has the performance benefits that the
>>>> multi-doc api has ... but it certainly would be handy to have around when 
>>>> we
>>>> need it.
>>>>
>>>>
>>>> - Chad
>>>
>>> Hi Chad, I did some work on submitting multiple queries to a single view in 
>>> one POST to that view.  I'll try to clean it up and submit the patch this 
>>> week.  Multiple queries to different views in the same view group would be 
>>> a straightforward extension internally, but I'm not sure what the HTTP API 
>>> would look like for that.  Queries to different view groups should always 
>>> require separate requests IMO.
>>>
>>> The case to track this would be 
>>> https://issues.apache.org/jira/browse/COUCHDB-523 - please feel free to 
>>> comment, especially if the proposed feature doesn't meet your needs.  
>>> Cheers,
>>>
>>> Adam
>>>
>>>
>>>
>
>

Reply via email to