couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: Candidates for built-in filter functions?
Date Tue, 22 Mar 2016 12:28:52 GMT
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 <rnewson@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 <kocolosk@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 <kxepal@gmail.com>
> wrote:
> >>
> >> On Sun, Mar 20, 2016 at 7:30 PM, Constantin Teodorescu
> >> <brailateo@gmail.com> wrote:
> >>> On Sun, Mar 20, 2016 at 6:19 PM, Robert Newson <rnewson@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
> >>
> >> --
> >> ,,,^..^,,,
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message