couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: Clarifications or bugs
Date Fri, 11 Apr 2008 07:26:36 GMT
On Thu, Apr 10, 2008 at 11:31 PM, Søren Hilmer <> wrote:
>  My problem is that couchdb only tells me which database has changed, with
>  that information I can get the documents changed, but now I need to run
>  the views to index on these documents (and preferably these documents
>  only) in order to get what I need to index. I believed I could filter on
>  the documentid (startkey_docid) but that is apparently only supported in
>  conjunction with startkey (which I do not know, as I haven't ran the view
>  on the document yet).

I'm afraid this is significantly different from the architecture as it
currently stands, but if the indexer were to be called with the output
of each emit() function from the view engine, it would clear up a lot
of these problems. Since the view engine is already external to
CouchDB and communicating over stdio, it seems like a decent
opportunity to attach other processes as well. CouchDB could be set to
send the result of each view (at least those that are configured to be
full-text searchable) along with its corresponding document to the
full-text indexer, at view-compute time. The full-text indexer would
be called once per emit, so it could easily handle cases where a given
document shows up in the same view multiple times.

To me this seems simpler than trying to pick up changes that could be
anywhere in the view sort order. The gotcha may come when the
view-engines are distributed across instances. Then the problem
becomes managing a distributed full-text indexing process...

Hopefully this is helpful.


Chris Anderson

View raw message