2009/7/20 Chris Anderson <[email protected]>: > Devs, > > I've just committed a patch (r795687) that adds the ability to filter > _changes requests with a JavaScript function. > > The function signature is: > > function(doc, req, userCtx) { > return (true or false); > } > > When it returns true (or something truthy, like a non-empty string or > a non-zero number), the change is passed along to the user, otherwise > it is skipped. > > The filter functions are stored on design documents under the > "filters" field. The current best source of documentation is the > changes.js test. > > To query changes with a filter, the syntax is like: > > GET /db/_changes?filter=ddocname/filtername
A URL of /db/_design/ddocname/_changes/filtername would be more consistent, IMHO. It also means *any* query arg gets passed through with no special case for 'filter'. Parsing the URL also "passes through" the design doc, which may have some significance in the future (design doc -level filters, security, or whatever). > > The biggest problem with this patch is that it uses a JavaScript OS > process per connected filtered listener. Fixing this is an > optimization as it won't effect the API, which is why I'm comfortable > committing this. > > I'd appreciate some review to make sure the implementation is on the > right track. > > Cheers, > Chris > > -- > Chris Anderson > http://jchrisa.net > http://couch.io >
