Improves the query time from 23 s to 1.5 s on my untuned dev instance for top10 queries and yearly overview queries. We have a little bit of wiggle room in history table upserts that we can afford the extra index update on history creation/completion to compensate from these otherwise very slow queries.
Index on the name makes it so that the query to check if a torrent of the same name already exists upons upload is instant instead of taking 600 ms. Index on user_id, status, anon, deleted_at makes home page load instantly instead of taking 10+ seconds to calculate user stats.
- Change primary keys of category_id, resolution_id, type_id to unsigned smallint
- Checking if any torrents/requests exist with non-existent categories/resolutions/types
if so, create a new category/type/resolution called "Other"
- Update the related id to the Other relation
- Adds constraints with on delete restrict for these relations to the torrents and requests tables
These permissions were never meant to be directly edited by staff. They should never have been added to the staff user edit page as it just caused confusion when the settings reset at the daily group change. I've now added these settings to the group directly and allow the settings on the user edit page to override the group settings. I refrained from fixing the can_download permission for now, because so many different things affect it and it will need at 3 separate permissions to control everything it does. Trying to fix it will take much more effort than what can be fixed today. Because of this, I removed the setting from the user edit page to reduce confusion from staff who don't realize it is controlled by the scheduler. Relevant issue: #1820.
fixup of 8c11521. It was unintentionally changed from varbinary to binary. The ip column must not be fixed length, since mysql will right pad the other 12 bytes of 4-byte ipv4 addresses with NUL (`\0`) bytes, which breaks `INET6_NTOA()`. The full 16 bytes are needed for ipv6 addresses however. Note that the commit this fixes isn't yet in stable, so anyone running the development branch in prod will have to update their schema manually.
Allows users to more easily see when they were prewarned in case they no longer have their notification.
It was decided to discard previous prewarn values and have the system prewarn users again if applicable.
It was decided that keeping the history of prewarn values wasn't valuable for this migration.
In laravel 11, they changed the syntax for changing columns so that all constraints are removed and reapplied, compared to only adding constraints that weren't added before. I generated the sql code of each migration on laravel 10, and the same on laravel 11, and compared the sql code between the two versions and changed the migrations so that the sql matched between the two versions.
After 10+ hours of debugging and searching through livewire issues, it turns out that the query string doesn't update if you have `history: true` in the `#[Url()]` attribute.
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.
HDVinnie