v2: recent searches

[josh-chamberlain]

Context

Part of https://github.com/Police-Data-Accessibility-Project/data-sources-app/issues/274

Requirements

• We should track ~50 recent searches for each user (similar to #26)
• When a user hits the search endpoint, we should store their request somehow.
• We should have an endpoint for retrieving all of a user's recent searches

@maxachis says:

For the backend, I see this involving:

1. A new table user_recent_searches, which links between the user and quick_search_query_logs table (or whatever inherits from it.
2. Additionally functionality upon hitting a search endpoint where, if it's an actual user, we add their entry to the above linking table.

Not terribly challenging.

Tests

• TBD

Docs

• API docs should occur naturally

[maxachis]

This could be even simpler than I previously envisioned it -- with the new locations table (which is suggested in /typeahead/locations and utilized in /search, we can simply provide the location id (and if necessary, the record or record category id) of the user in this user_recent_searches table.

The only slightly tricky part is having the table behave as a rolling queue, where the least recent entry is deleted and replaced by the new entry if there are 50 entries for that user. I'm sure there's a way I can implement that via triggers.

Additionally, @josh-chamberlain : Do we want to store when the search was made, or is it enough to know that it was made?

[josh-chamberlain]

@maxachis cool! I think storing when a search was made is a good idea, if only for debugging.

[maxachis]

@josh-chamberlain This issue, as it exists right now, does not include an endpoint for retrieving the recent searches of a user. Should that be considered a part of this issue?

[josh-chamberlain]

@maxachis caught! edited the issue to make specific note of it. Yes, I think so.