That idea came up explicitly this week and it has obvious merit. I don't know enough about mango selectors to know if it's rich "enough" but it would be simple to add and whatever it did cover would run much faster than today's JS approach.
> On 20 Mar 2016, at 17:03, Adam Kocoloski <kocol...@apache.org> wrote: > > Hi Bob, instead of trying to anticipate all popular options what about > enabling Mango selectors as filters? I’d hope that over time the performance > of a selector is comparable to a builtin. > > Adam > >> On Mar 20, 2016, at 12:34 PM, Alexander Shorin <kxe...@gmail.com> wrote: >> >> On Sun, Mar 20, 2016 at 7:30 PM, Constantin Teodorescu >> <braila...@gmail.com> wrote: >>> On Sun, Mar 20, 2016 at 6:19 PM, Robert Newson <rnew...@apache.org> wrote: >>> >>>> As part of a new effort to improve replicator performance I'm planning to >>>> add new built-in filter functions. These run in the Erlang vm; saving the >>>> couchjs round trip. >>>> The first candidate is one that skips deleted documents as it's quite >>>> common to replicate with such a filter to remove deleted tombstones. >>>> This thread is for gathering more suggestions, so please help me out here. >>>> I'd like to reach the level we have for reduce functions which cover a good >>>> deal of the useful / functional cases. >>>> One filter I'm considering would allow filtering by the value of a named >>>> attribute. Something like "include this doc if doc.type equals 'purchase >>>> order'". Both the name and required value would be query parameters. >>>> >>> >>> It would be nice also: _design/* or even something like _id match regexp >>> ... >>> And the same for doc.type match regexp >> >> That's the way to have a security issue by giving arbitrary user to >> run any regexp on server side. For instance: >> http://www.regular-expressions.info/catastrophic.html >> >> -- >> ,,,^..^,,, >
