Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.132.244 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=HywrNE9w5D13ac9ycRatmR0kB9nddE3HqY5+LfuBI3TAiTOGKlOjgg9yQT3Rn43YQ0
         uI+wRvbMbiWR1Il000zz7NnKS7xw1Dtpn77XSUGyzy7Cc3lAXZ4094MGfl7N6eOCQVEp
         TR4Ay9oCgv109qYAOljcH1XRaOOsvlZP5ec4E=
Message-ID: <e2111bbb0807031423s1e987d4jf8d928200b37e86b@mail.gmail.com>
Date: Thu, 3 Jul 2008 17:23:00 -0400
From: "Paul Davis" <paul.joseph.davis@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: Re: Views using JSON Arrays
In-Reply-To: <29228.24868.qm@web57207.mail.re3.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <29228.24868.qm@web57207.mail.re3.yahoo.com>

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 <bradswinfrey@yahoo.com> 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 <damienkatz@gmail.com>
> To: couchdb-user@incubator.apache.org
> 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 <bradswinfrey@yahoo.com
>>>> > 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
>> --
>
>
>