On Thu, Apr 10, 2008 at 11:31 PM, Søren Hilmer <[EMAIL PROTECTED]> 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 -- Chris Anderson http://jchris.mfdz.com
