[performance] improved enum migrations

[NyaaaWhatsUpDoc]

Description

This improves our shared enum migration function to use a singular update query that handles all possible variations using a CASE statement (thank you for the suggestion @mirabilos !). I probably should have gone with this approach first but our ORM doesn't expose CASE logic so it hadn't initially jumped to mind. The ups-and-downs of ORMs, eh!

I ran this on our test suite (which isn't always the best test of migrations) with both SQLite and Postgres just fine. And I had an old backup of my own database which I was able to use to confirm in a production-like environment that this definitely works on SQLite. Obviously if anyone has an old backup of some Postgres data to test this against feel free to let us know and we can wait for a test on that!

Checklist

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have not leveraged AI to create the proposed changes.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[tsmethurst]

Nice one :)

[mirabilos]

On Tue, 11 Feb 2025, kim wrote: This improves our shared enum migration function to use a singular update query that handles all possible variations using a CASE statement (thank you for the suggestion @mirabilos !). I probably

Cool!

should have gone with this approach first but our ORM doesn't expose CASE logic so it hadn't initially jumped to mind. The ups-and-downs of ORMs, eh!

Yeah… it took me a while, and learning SQL *properly*, but now I’m on the “not using ORM other than for trivial CRUD queries” side, with “SQL-first” schema design. (A while is… I think roughly ten years here.) An ORM is really helpful in the beginning, if you have an OOP approach and your queries do mostly resemble CRUD, but as soon as you need to write slightly complex analysis queries, or, as you’ve noticed, migrations, and still want to be performant, it reaches its limits. I’ve seen others use the ORM for the simple queries and the ORMs’ ability to forward and run native SQL (if not HQL or so) for more complex queries, too. Cool that you had the backup around and could verify it, so that everyone who hasn’t yet had that migration can benefit from it. Thanks, //mirabilos