Just toying around looking at the code but I think implementing this wouldn't actually be that difficult.
The two important functions are: parse_view_query and make_view_fold_fun in couch_httpd.erl The basic idea would be to change the key, startkey, endkey behavior to be a list of keys instead of just two values. (Currently, key=blah translates to startkey=key and endkey=key. Changing this to a list and then adding a flag to emit all docs between the first and last key vs. only docs that match one of the keys). The only gotchya here I think would be making sure that the list is sorted properly based in the direction argument. Also, this list would have to be sorted in parse_view_query because the beginning fold needs to know the start key. (Not sure on erlang specifics, but I imagine there's a standard "sort_list_using_func_as_comparator that you could just pass the couch_view:less_json function) Then in the make_view_fold_fun in the PosCount and NegCount functions in the case block that appends a new object to the response you would just check that the key is in your list which could be done fairly efficiently in a merge sort manner. I don't know about Damien's comment on using a post body code wise. But I would imagine that passing the post data to the parse_view_query should be fairly easy. Now all I need is an erlang hacker.... Damn it Jim! HTH, Paul On Thu, Jul 3, 2008 at 4:18 PM, Bradford Winfrey <[EMAIL PROTECTED]> wrote: > So it's not something so simple as to do... > > http://...?keys[]="val1"&keys[]="val2"; as the request. Meaning keys is an > array and then checking to see if the key being emitted exists within the > array that we passed in? I'm totally firing this off before looking at the > code, so bear with me... > > > > ----- Original Message ---- > From: Damien Katz <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, July 3, 2008 1:51:38 PM > Subject: Re: Views using JSON Arrays > > > On Jul 3, 2008, at 2:34 PM, Jan Lehnardt wrote: > >> >> On Jul 3, 2008, at 20:17, Jan Lehnardt wrote: >> >>> >>> On Jul 3, 2008, at 20:07, Paul Bonser wrote: >>> >>>> On Thu, Jul 3, 2008 at 8:01 AM, Bradford Winfrey <[EMAIL PROTECTED] >>>> > wrote: >>>> >>>>> We would get back each one of our tags as a key, yea? Only if we >>>>> supplied one at a time. So how does one go about supplying a >>>>> range, array (not sure what we'd call it here) of keys to be >>>>> searched on? http://...?key=["octopus","hockey";] maybe? I'm >>>>> unsure of the plan of attack for such a thing. Maybe I'm just >>>>> going about it in the wrong direction. Any thoughts? >>>> >>>> Hey everyone. I've pretty much just been watching the mailing list >>>> here myself. >>>> >>>> This is the second time somebody has asked about this since I've >>>> started watching this mailing list. I could see it being a valuable >>>> feature. >>>> >>>> Would it be valuable to add the ability to query a view with >>>> multiple >>>> keys, getting the results for each of those keys back? Something >>>> like >>>> http://...?key_list=["octopus","hockey";] >>>> >>>> If I were interested in investigating how hard it would be to add >>>> that >>>> feature, where would I start looking in the code? >>> >>> This simply doesn't fit the way views work. They are single indexes >>> that you >>> can use for single-key or or key-range lookups. if you need random >>> access >>> you'd basically need to query the view as many times as you have keys >>> to search. No matter if you do that in front or behind the API. >> >> Hey you smart-ass, on the one hand you are trying to recruit new >> developers and on the other hand you discourage people from adding >> useful features. Make up your mind man! >> >> Paul, if you come up with a nice solution, we'd be happy to look at >> integrating it. Please give it a try. To investigate the code it is >> probably >> best to start at src/couchdb/couch_http.erl as it defines the HTTP API >> and handles the requests you already know and just drill down from >> there. > > :) > > The view indexes can indeed do multiple lookups at once. 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. > > >> >> >> Cheers >> Jan >> -- > > >
