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 Mon, 24 Aug 2009 07:14:41 GMT
On Mon, Aug 24, 2009 at 8:40 AM, Adam Jacob<adam@opscode.com> wrote:
> On Sun, Aug 23, 2009 at 3:20 AM, Tom Sante<tom.sante@gmail.com> wrote:
>> 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.
>
> Just out of curiosity, why would you want to have the CouchDB server
> handle the join like this?  Unless you are doing some fancier magic to
> keep the combined view up-to-date (ie, kicking rows out of the M-Set
> only when a sub-view has changed, etc.) I'm not sure I see why you
> would want to centralize a heavy-weight operation rather than
> de-centralize it.  What am I missing? :)
>
> Adam
>
> --
> Opscode, Inc.
> Adam Jacob, CTO
> T: (206) 508-4759 E: adam@opscode.com
>

If I'm combining thousands or millions of rows into one result set I
want my server to handle it and not some hacked together javascript on
the client side.
It's gonna be a lot faster, especially with some caching to avoid
repeating the same unnecessary work. Same reason you don't just send a
client app all docs and let it handle the view generation. The point
is, you have your database server handling the data and your client
side app handling client side stuff, and not mix things up.

Mime
View raw message