Implement filtering options for Boolean types

[kgodey]

Problem

We need to ensure that records that include columns of Boolean type support the following filters via API:

• is {true/false}
• is not {true/false}
• is empty
• is not empty

This may already be done, please verify that it works and add some test cases specifically for boolean data types.

This involves:

• Implementing the filters in the backend
• Updating the /api/v0/databases/<id>/types/ endpoint to store available filters on this type
  • Filter information should include the number of parameters needing to be passed in (e.g. is needs 1 parameter, is empty needs 0)

Additional context

• We're using our fork of sqlalchemy-filters to provide filtering. See: https://github.com/centerofci/sqlalchemy-filters.
• See also: Handle BOOLEAN data type in the backend #387
• Update filtering issues to cover storing filter/group information in the backend. #557 provides some context on storing filters.

[powellc]

This seems to be functional already. Adding tests and the available filters on the type endpoint.

[eito-fis]

@powellc You might've seen this already, but there are already some tests for filtering at db/tests/records/test_filtering.py. It lists all the operators that are implemented by sqlalchemy-filters which might be useful.

And if you need to update our fork of sqlalchemy-filters, I've been working off this branch. If it needs to change, it might be worth properly organizing that repo and getting things merged into master and updating the readme - let me know and I can help out.

[powellc]

That's great @eito-fis, thanks! I hadn't see the filter tests yet. Do you think it makes sense to still test the filtering via the API, or would these test suffice to cover that logic? I think I'm leaning towards also adding tests to the mathesar/tests/views//api/test_records_api.py file, but I could be conviced not to 😄

[eito-fis]

I was previously testing all the filtering on the backend and then just ensuring the API called the function with the right arguments. At the time it wasn't very principled, but I liked that the db tests ran faster than the API tests (django db gets reset between api tests) so I went with that.

[kgodey]

@powellc @eito-fis I think it makes sense to add tests to the API for each data type to ensure that we support the specific filters for that data type.

[powellc]

Sounds good! I'll push up some API tests for filtering around booleans in a bit. Thanks!