Feature: Generalize Search to Other Models

[michael-genson]

What type of PR is this?

(REQUIRED)

• feature

What this PR does / why we need it:

(REQUIRED)

This generalizes the recipe search from #2351 to work for any model. After these changes, adding search support to a model is as easy as:

1. adding a list of strings of searchable fieldnames to the searchable model
2. adding the search param into the model's get_all route

Which issue(s) this PR fixes:

(REQUIRED)

N/A

Special notes for your reviewer:

(fill-in or delete this section)

This PR does not add normalized fields to the newly-supported models, so diacritics and symbols will decrease search accuracy. In the future I want to re-work how the recipe parser finds food/unit matches (using this search API) and that PR should add normalization. I figure it's okay to not normalize in this PR since often it's a less common issue, and fuzzy matching will work around it anyway (if using postgres). We'll probably also want to index those fields (similar to recipes).

If you think this PR should normalize search fields, I'll happily add them, I just didn't want this PR to become too much of a headache (since normalized fields will add migrations) for little benefit (the frontend isn't using this API yet).

Testing

(fill-in or delete this section)

I refactored the recipe search tests to be parametrized (instead of one large test) and added a generic set of tests for units (since recipes use a more complex filter, including ingredients). They probably don't need to both be there, but they're good tests, so I think it's fine.

I also tweaked the tests to allow extra results (e.g. if only one recipe is expected to match, and two match, that's fine, as long as the first one is the one we wanted) to avoid those annoying test failures we've seen in other PRs. I also sandboxed them using their own user/group to avoid other tests leaking in.

Release Notes

(REQUIRED)

added APIs to search for foods, labels, units, categories, tags, and tools

[jecorn]

This is awesome! And the test refactor is super appreciated. Trigram matching can be very slow on columns without an GIN index, so like you said it’s probably a good idea to index anything that will be searched.

[michael-genson]

Thanks! I pretty much just copy pasted what you worked on and reorganized things a bit. And yeah, my thought process here is to add a quick win for expanding the search, then we can normalize/index anything we use on the frontend.

Unless we want to do that upfront now, I just wasn't sure