Hi Benoit, all, I'm not too happy with how this turned out.
There's multiple things this patch is trying to solve and by thinking about them separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid special casing for situations we think are common but turn out not to be. 1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could be built-in. This would allow us to add more built-in filter functions in the future when we discover patterns there. 2. POST-ing arguments to _changes. This is needed because there are practical limits on the URL length so we can't send a large number of URL parameters. This is the same reason we have POST to views. Together, 1. & 2. can solve what you need and they also help us keep the improvements Filipe said could be roll into the replicator while at the same time we don't code ourselves into a corner for future additions. What do you think? Cheers Jan -- On 13 Oct 2010, at 17:24, Benoit Chesneau <[email protected]> wrote: > Hi all, > > For a project I have to know each time a design doc change and for now > I have to create a filter function for each databases created to do > that. I think getting changes on specific docids is a common behavior > (see replication for example) so I thought to add the possibility to > filters changes on docids if a list of documents is passed in the > request. > > ex: > > POST /db/_changes > {"docids": ["id1", ..]} > > > Here is the patch that allows that feature : > http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8 > > What do you think about it ? > > - benoit
