On 18 Oct 2010, at 12:34, Benoit Chesneau wrote: > On Sun, Oct 17, 2010 at 7: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. > > What d you mean by built-in filter ? How would it be called ? If it's > like _count in reduce function it doesn't solve the case i'm trying to > solve, ie not creating a function for common case. But I think you > mean smth like built_in=... , but am not sure it's needed here since > we have only one case on POST. > > So which usage do you expect ? Any example?
I'm thinking: GET /db/_changes?filter=_doc_ids Where _doc_ids references a built in Erlang function that does filtering by doc id. Much like _sum or _count for reduce. How does your scenario differ from this? Maybe I'm just unclear on it. Cheers Jan --
