couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Sante <tom.sa...@gmail.com>
Subject Re: How to code an advanced search
Date Sun, 23 Aug 2009 10:20:08 GMT
Like adam said, refactor each of those questions into a single view for each.
When you want to do a combined/advanced query send it to an external process:
http://wiki.apache.org/couchdb/ExternalProcesses

The external process is a script (in a language of your choice) that
queries each view and handles the join logic and output json.
So you have the benefit that you don't have to tax the client with
heavy join calculations but still use couchdb as a proxy for handling
your query.
If you format the scripts json-output as a normal couchdb-return you
don't even need to modify your client code.

Tom

On Sun, Aug 23, 2009 at 12:03 PM, Tom Sante<tom.sante@gmail.com> wrote:
> 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
>>
>

Mime
View raw message