Backend text filtering

[dmos62]

Fixes #406

Depends on previous filtering PR: #837

Introduces StartsWith, EndsWith and Contains predicates for text types. These predicates accept a case_sensitive setting (defaults to True).

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the master branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[silentninja]

Updated to the status to blocked, since it is blocked by #837

[dmos62]

Here's what the new entries in the /filters endpoint look like:

GET /api/v0/databases/1/filters/

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

[
    ...,
    {
        "identifier": "or",
        "name": "Or",
        "position": "branch",
        "parameter_count": "multi",
        "ma_types": [
            "boolean",
            "datetime",
            "duration",
            "email",
            "money",
            "number",
            "text",
            "uri",
            "other"
        ],
        "settings": null
    },
    {
        "identifier": "starts_with",
        "name": "Starts with",
        "position": "leaf",
        "parameter_count": "single",
        "ma_types": [
            "email",
            "text",
            "uri"
        ],
        "settings": [
            {
                "identifier": "case_sensitive",
                "name": "Case sensitive",
                "default": true,
                "python_type": "bool"
            }
        ]
    },
    {
        "identifier": "ends_with",
        "name": "Ends with",
        "position": "leaf",
        "parameter_count": "single",
        "ma_types": [
            "email",
            "text",
            "uri"
        ],
        "settings": [
            {
                "identifier": "case_sensitive",
                "name": "Case sensitive",
                "default": true,
                "python_type": "bool"
            }
        ]
    },
    {
        "identifier": "contains",
        "name": "Contains",
        "position": "leaf",
        "parameter_count": "single",
        "ma_types": [
            "email",
            "text",
            "uri"
        ],
        "settings": [
            {
                "identifier": "case_sensitive",
                "name": "Case sensitive",
                "default": true,
                "python_type": "bool"
            }
        ]
    }

Notice:
- Every entry has a settings field; it can be null: I opted to always include it for consistency;
- The new predicates starts_with, ends_with and contains declare that they accept a case_sensitive setting, its UI-friendly name, that it defaults to true and is a boolean;
- The setting value type (python_type) is specified in terms of the python type used (bool in above cases); without making assumptions about the client, this could also be a JSON type, since that's the data notation used, but that will require a client-side map between API types and client-side types too, so I stayed with Python types.

The settings are provided like this:

{"starts_with": {"column": "col1", "parameter": "a start", "case_sensitive": false}}

The architecture around how we deal with predicate settings, like case-sensitivity in this case, is minimalistic and fluid at the moment since requirements aren't clear yet. We're currently working from simple cases to more complex ones, so I expect refinement to take place in future PRs when more interesting predicates are explored.

[kgodey]

@dmos62 I made this PR a draft so we don't accidentally merge it. I think it's fine for the status to be review.

[dmos62]

@kgodey this last commit makes internal nomenclature changes you requested: super type -> position, type -> id. It makes some other significant changes too; I forgot to commit before making other changes.

[dmos62]

@kgodey this last commit makes internal nomenclature changes you requested: super type -> position, type -> id. It makes some other significant changes too; I forgot to commit before making other changes.

I reflected on this a bit and decided that introducing changes only to the last PR when they are relevant to a series of PRs is not a good idea. Next time, I'll commit to the oldest PR and merge the older PR into the newer PRs.

[kgodey]

I reflected on this a bit and decided that introducing changes only to the last PR when they are relevant to a series of PRs is not a good idea. Next time, I'll commit to the oldest PR and merge the older PR into the newer PRs.

Agreed, I assumed it was because the other PR was based on a fork and this is a branch. I do think it's always better to make it on the older PR.

[kgodey]

@dmos62 Can we close this PR since it's pretty out of date?