No, you couldn't change returned document via filter_view. It just works as regular filter, but it generates "passed" state for documents that have been emitted by view map function at least once. You probably wanted of some kind real-time view result stream? Filter_view call doesn't update view index if I understood Jan right, so you still have to make pure view function call to make result being indexed and accessible.
About other new filter I know nothing, may be Jan or somebody other could tell more. However, it doesn't present in query server now or I've missed something interesting(: ------------------ ,,,^..^,,, On Mon, May 16, 2011 at 7:42 PM, Joe Freeman <[email protected]> wrote: > On 16 April 2011 16:42, Alexander Shorin <[email protected]> wrote: >> On Sat, Apr 16, 2011 at 7:26 PM, Joe Freeman <[email protected]> wrote: >>> Is there a way to pass the _changes feed (with include_docs=true) >>> through a map function (for example, one that exists as part of an >>> existing view)? If not, are there any plans for this? >> >> This functionality is already in trunk/1.1.x branch >> https://github.com/apache/couchdb/commit/56086f07c425bd272bda5a6609ed9db3758178ba > > Sorry to bring up an old thread, but having had a second look at that > commit, I'm not sure it's really what I'm after. > > The feature I'm after involves being able to have a _changes feed with > include_docs=true which also gives me the ability to pass each > document through a map function first so that I can remove unnecessary > (and potentially big) parts of the document. At the moment I have to > listen to _changes, and then for each change, I do another HTTP > request to find out what the change involved - I was hoping to skip > out this extra request. > > Perhaps I'm mis-understanding that commit and it does actually do what > I want? Or maybe I'm after the 'other' mechanism that Jan mentioned? > > Thanks. >
