Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 74.125.44.30 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=IoyFGptJTZGbqP8M3Nn+OifWQTqHcnl/dCU/Qds2WOosgcSrh2pzIbQx4FqArZ+r81
         1Ms22kpGOM/iWrE+s3EY449UFjxMTmkogZB4itJD78WBkG7EkAht2axsbGvRHDz0E+uk
         0hDC2yN9bctgTDeXBWUH6vfXbF//O8DIOb8K0=
Message-ID: <e282921e0901111539h69992853uab2eda4fb28db7cf@mail.gmail.com>
Date: Sun, 11 Jan 2009 15:39:34 -0800
From: "Chris Anderson" <jchris@gmail.com>
To: user@couchdb.apache.org, tech@dundeemt.com
Subject: Re: view intersections?
In-Reply-To: <5aaed53f0901111533x67802559rba91ffdcc2e7d021@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <5aaed53f0901111111n203347fcu15e5dde5ad62294c@mail.gmail.com>
	 <64a10fff0901111217l14d07cd2p2f03146cc08d8f82@mail.gmail.com>
	 <5aaed53f0901111449u15032cdbq2a1d7730cb134efe@mail.gmail.com>
	 <5aaed53f0901111533x67802559rba91ffdcc2e7d021@mail.gmail.com>

On Sun, Jan 11, 2009 at 3:33 PM, Jeff Hinrichs - DM&T
<dundeemt@gmail.com> wrote:
> On Sun, Jan 11, 2009 at 4:49 PM, Jeff Hinrichs - DM&T
> <dundeemt@gmail.com> wrote:
>> On Sun, Jan 11, 2009 at 2:17 PM, Dean Landolt <dean@deanlandolt.com> wrote:
>>> On Sun, Jan 11, 2009 at 2:11 PM, Jeff Hinrichs - DM&T <jeffh@dundeemt.com>wrote:
>>>
>>>> I've been reading and googling trying to figure out the proper way to
>>>> do an intersection of views.
>>>>
>>>> The database has documents with an attribute of tags (a list)
>>>> ['copper','blue','hot','long','twisted']
>>>>
>>>>
>>>> If I wanted to find all documents that had the tags of 'copper' and
>>>> 'blue' what is the preferred way?  I could index all the elements of
>>>> the tags list and then perform two requests key='copper' and
>>>> key='blue' and have the client do the intersection.  Is there a way to
>>>> have couchdb do the lifting on this one?
>>>>
>>>> Along the same line, what of the union of tags. 'copper' or 'blue'
>>>>
>>>
>>> Two requests, then merge on the client. It's not really a pattern that fits
>>> the map/reduce paradigm well. I don't know the status of the fti
>>> integration, but once that goes down there should be more efficient ways to
>>> handle this.
>>>
>> True enough that it doesn't fit the map/reduce paradigm, but the
>> intersection would be performed post map/reduce. ?? Just like
>> key/startkey/endkey/limit are not part of the map/reduce picture, they
>> appear to be implemented separately to operate on the results of the
>> view created by map/reduce.   This would be an enhancement to querying
>> the view, not in generating the view itself.
>>
>> Feel free to slap me down, as I'm talking from someone who has not
>> looked at the source, is fairly new to couch and is talking from
>> limited experience(I've got thick skin and a desire to learn :).
>> However,  set intersections and to a lesser degree, joins, are a
>> common and useful idiom especially when working with sets.  And views
>> are sets, couchdb already supports limited set operations by giving
>> simple sub-select operations.  The reason, I'm guessing, is do to the
>> natural idiom and freeing the client from doing the work.
>> Intersections are a natural progression of view querying, in my
>> opinion.
>>
>> trying-to-get-someone-else-to-do-my-work'ly,
>> -Jeff
>>
>
> Ok, so now I read the documents and I am able to comprehend things I
> missed before.  couchdb 0.9 can do a union query on a view,  from,
> http://wiki.apache.org/couchdb/HTTP_view_API - Query Options
>
> "A JSON structure of {"keys": ["key1", "key2", ...]} can be posted to
> any user defined view or _all_docs to retrieve just the view rows
> matching that set of keys. Rows are returned in the order of the keys
> specified. Combining this feature with include_docs=true results in
> the so-called multi-document-fetch feature. "
>
> I've verified that
>  curl -X POST --data '{"keys":["short","red"]}'
> http://localhost:5984/delasco-tests/_view/tags/by_family_tagvalue
> returns a union of key="short" or key="red" over the view.  This is
> great because it means someone smart is already thinking about this.
> Now if this thread can just convince those people to take the next
> step and continue on and cover intersections for multiple keys on a
> view in the same spirit!
>
> This does bring a question to mind, why is this implemented as a POST
> and not a GET.  Wouldn't REST dictate that since it doesn't update the
> data a GET would be better?
>

It was implemented as a POST because of limits on URL length that make
GET not useful for many many keys.

I fully support any patch that adds GET support where ?keys=JSON_ARRAY
but we can't drop POST without limiting ourselves severely.


-- 
Chris Anderson
http://jchris.mfdz.com