HI, I thought about this a bit a while back. I think a one off replication of a view (e.g. snapshotting the view) is fine, but it gets trickier with a continuous replication - how do you work out the _rev's? If you pull all the docs across as part of the replication why not just replicate the whole database not the view? If the view is just a subselection of the database (e.g. docs with a certain parameter) then why not use a filtered replication? I think a filter on a view would be useful but wouldn't be very performant vs view slicing (since it would have to be calculated for every request, as opposed to the view which is stored to disk, including the reduce step). It might help transition people to using couch to allow more server side behaviour, people do seem to worry about concurrent requests to the server more than necessary (though reducing round trips to the server would be good), but it's probably better to demonstrate how to do filtering with correct view construction and slices. Also, unless you're going to filter GB's of data down to kB's (which is going to be hell for the server) you're probably optimising in the wrong place. Filtering in the client isn't hard on a reasonable dataset and means the server is freed to serve another request. Cheers Simon
On Sunday, 29 January 2012 at 14:35, Dave Cottlehuber wrote: > On 29 January 2012 18:13, Benoit Chesneau <[email protected] > (mailto:[email protected])> wrote: > > On Sun, Jan 29, 2012 at 8:54 AM, Daniel Gonzalez <[email protected] > > (mailto:[email protected])> wrote: > > > > > > > > - Am I doing something wrong in the curl calls? > > > - Is it at all possible to use views together with filters, or are > > > filters limited to the _changes feed? I have seen no examples of > > > filters except related to _changes > > > > > > > > > > > filters are only expected for _changes. > > > > - benoît > > Although it might be interesting to factor out filters (in changes and > replication) and to manage them the same way as views, including being > able to use views as replication targets, and avoid needing to > reprocess the filter each time. > > I'm sure that when I think about this after my wine, I'll come up with > some good reasons why thats not a great idea. > > A+ > Dave > >
