The query only takes 6 seconds on my local untuned machine. Caching it for an hour is probably fine, we have worse queries out there, and indexing isn't an option since this table is write-heavy. Reduces overall complexity and prevents blank page after cache is reset.
Use a 1-1 relation. Cache it indefinitely to reduce queries for every http request. This will make it much easier to add additional user settings for various site features without sacrificing clean code or performance.
All changes were tested for performance regressions. None of the included changes were affected. However, the code that uses `whereIn('category_id', Category::select('id')->where('movie_meta', '=', 1)` saw a ~10% performance loss so should not be changed.
Now that we upsert history records without first selecting them, we can't rely on storing a peer's last uploaded/downloaded values in the history record to determine the user's uploaded/downloaded delta between the last announce. If a user has internet issues for a brief period of time but their client continues working, then their change of upload/download between the two announces needs to be kept track of. This is usually kept track of in the peer record, but if the peer is deleted after 2 hours of not announcing, then their last uploaded/downloaded data is deleted with it. We previously stored this data in the history table to handle such cases but this became erroneous if the user had multiple peers on a torrent. This new solution keeps the peers in the database for 2 days before concluding that the peer isn't coming back and deletes the peer permanently. After which point, a new peer will be created and an assumption is made that they uploaded/downloaded 0 data within their downtime.
Use eager loading where necessary and add a few indexes. The existing index on private_messages for sender_id and read was probably a typo and intended for receiver_id. The first 3 tables indexes are added to are used for queries ran on every page load: namely the new pm, new notification and warnings indicator in the navbar. Additionally, another index on genre_movie proved useful for finding all the genres when given a movie id. Perhaps, another index for finding all movies within a genre would be good as well, but will leave that for a future optimization if deemed necessary.
- github action updated with new ruleset in pint.json
- codebase linted with new ruleset
- contributors can now run `./vendor/bin/pint`
- action workflow will auto correct any lint issues upon commit/opened pull request
