Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of fredericmalo@gmail.com
 designates 209.85.218.211 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=neKLU1QB9BlPyVefZPmMQNvgQj8kTbQkq1IzpAoKC6XThy/tKNi7gZwnjly7bDtihj
         XeGFhkewIex+IZDj2JXwc+9yxFIPKjSHI6SB8XZoWUgTppTIDjlUGE/SxkgxPotzgizr
         suXuhczdldgXMW/KiLY98ABYOZYJWSmcsbjW4=
MIME-Version: 1.0
In-Reply-To: <b8602b350908171411j29b5c378u9ba5e5544ebedb00@mail.gmail.com>
References: <bf14df3a0908160129h556b7946x6d5166c6320fea30@mail.gmail.com>
	<b8602b350908171411j29b5c378u9ba5e5544ebedb00@mail.gmail.com>
From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Malo?= <fredericmalo@gmail.com>
Date: Wed, 19 Aug 2009 09:44:17 +0200
Message-ID: <bf14df3a0908190044l24f40667v178f32e8aca18399@mail.gmail.com>
Subject: Re: How to code an advanced search
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0023545bd7608c7aa5047179ceb0

--0023545bd7608c7aa5047179ceb0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Adam,

So the JOIN logic is not hosted in couchDB but in the application layer. Th=
e
benefit is scalability, but a little more work :-)

Fr=E9d=E9ric


On Mon, Aug 17, 2009 at 23:11, Adam Jacob <adam@opscode.com> wrote:

> On Sun, Aug 16, 2009 at 1:29 AM, Fr=E9d=E9ric Malo<fredericmalo@gmail.com=
>
> wrote:
> > For example, imagine a music database as iTunes. I would like to create=
 a
> > script to query such as :
> >
> > Sort all songs by genre then album  :
> > - with 3 or 5 stars
> > - artist name matching "floyd"
> > - duration between 5 and 8 minutes
> > - heard last week (perhaps another couch database, logging user actions=
)
> > - ....
> >
> > All the parameters are optional. Users can choose to filter with only 2
> or 5
> > parameters. Other parameters should be added.
>
> The simple answer is "you can't get there from here", at least not
> like you are thinking.  You have a couple of options:
>
> * Refactor each of those questions into a single view for each, with
> the key pointing to a list of songs that match.
> * As the user adds more options, you are actually adding an extra
> request for each view
> * Use the built in sorting to get the sort order
> * Query all the various required views and return the final result set
>
> This is following a similar pattern to the ones used by Full text
> search engines - you are using CouchDB to create the indexes for you,
> which return light-weight data that gets culled based on your
> requirements.
>
> Another option would be to actually put all this data into a full text
> engine, and use that. (Solr is a nice option here, and perhaps
> couchdb-lucene.)
>
> Don't be afraid to do a little more work on the systems that talk to
> CouchDB - often when you find yourself reaching for a Join, instead
> reach for multiple queries and doing the computation of the final
> match set yourself.
>
> Adam
>
> (I've seen a system that does just this, only with CDB indexes rather
> than CouchDB, do very complex queries and filtering against every
> hotel in America at very, very high speed.)
>
> --
> Opscode, Inc.
> Adam Jacob, CTO
> T: (206) 508-4759 E: adam@opscode.com
>

--0023545bd7608c7aa5047179ceb0--