On Mon, Oct 18, 2010 at 12:21 PM, Filipe David Manana <[email protected]> wrote: > On Sun, Oct 17, 2010 at 6:20 PM, Jan Lehnardt <[email protected]> wrote: >> 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. > > Exactly. Like we have the "special " reduce functions "_sum" and > "_count" for views for e.g. > >>
>> 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. > > Instead of a doc_ids parameter to changes, I was thinking that to > achieve the same goal, we could still use the "filter" parameter that > would have a different value for very common cases, starting with an > "_" just like for the special reduce cases. (the list of doc IDs would > then be a regular parameter to the builtin Erlang filter function) > having a parameter for that isn't really RESTful. We already have the POST meaning. Why do we need another param in url ? I've tjinking to the filter args before code that and rejected for abive reason. - benoit
