On 18 Oct 2010, at 20:36, Benoit Chesneau wrote: > On Mon, Oct 18, 2010 at 2:02 PM, Jan Lehnardt <[email protected]> wrote: > >> 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. >> > > That's working in my case. Though if for doc_ids we posts i'm not sure > passing a param is needed in this case since we already define the > request with a POST and a json body containing a doc_ids member. ALso > if we want to mix doc_ids + a filter it would be better to handle the > POST + different params to the filter query argument, I think. In > other cases that is perfect . I could allows to create for exaample a > builtin function to get all changed design docs in a db for ex...
I agree for your scenario using the explicit filter *and* a defined JSON key in the POST body is effectively duplication, but I think my approach is a bit more general and allows for future scenarios. I think specifying a built in filter function should work like specifying a regular filter function, except there's an underscore, as per CouchDB convention. I also like the idea of POSTing options to a filter function, but that should be possible for both custom and built in filter functions. That's why I think we should use a combination of both mechanisms to create a solution for your problem while being open for future uses of the same API. (Awful lot of starting sentences with "I", so yeah, this is highly subjective. :) Either way though, I think we should get this sorted before shipping 1.1.0 or migrating it to a feature branch so we can work on it and get it right for 1.2.0. (I talked to Benoit on IRC a bit and he agreed to tackle the changes I proposed. I'm happy to chip in, if needed.) Cheers Jan --
