couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: Are CouchDB filters limited to the _changes feed?
Date Mon, 30 Jan 2012 00:19:44 GMT
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.  

On Sunday, 29 January 2012 at 14:35, Dave Cottlehuber wrote:

> On 29 January 2012 18:13, Benoit Chesneau < (>
> > On Sun, Jan 29, 2012 at 8:54 AM, Daniel Gonzalez < (>
> >  
> > >  
> > > - 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message