I can't comment from an performance perspective. But from an api perspective, having the mango selectors for the filters would be really nice. I think it would be rich enough and quite elegant.
On Sun, Mar 20, 2016 at 8:40 PM, Robert Samuel Newson <rnew...@apache.org> wrote: > 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 > >> > >> -- > >> ,,,^..^,,, > > > >
