Add migration to update or add auth FK constraint in playertimes #1176
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1175. I decided to go with
ON UPDATE RESTRICT ON DELETE RESTRICT
referential actions instead of the CASCADE actions used by the constraint in DBs created <= v3.0.8. RESTRICT would have stopped the REPLACE SQLite query from working/cascading to delete all of the user's playertimes. It does mean that all child playertimes have to be deleted before the user table row can be, but this is already how DeleteRestOfUser works so should be fine.MySQL supports
ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY
. Unfortunately, SQLite does not, which means creating a temporary table to store existing playertimes data, dropping playertimes and re-creating playertimes with the correct FK constraint.For SQLite I initially tried
PRAGMA foreign_key_list(playertimes)
to test for the existence of FKs on playertimes, but the code was starting to get ugly so I switched to using sqlite_master and checking the SQL used to create the table. This meant using StrContains to check for <= v3.0.8 and >= v3.1.0 DBs which isn't exactly elegant (but it works).I tested this PR with a MySQL DB created at v3.0.8, v3.3.2 and a fresh DB with latest commits. Same for SQLite (with playertimes having >50k rows). Some more testing would definitely be good but should be working as-is.
Only concern I had was that this migration starts immediately after the first 9000 rows of Migration_DeprecateExactTimeInt, and for SQLite this means dropping playertimes and replacing the table without the exact_time_int column. Should be fine though since the id, exact_time_int combinations are still stored in DBResultSet results. If SQL_Migration_DeprecateExactTimeInt_Query fails for whatever reason though, it could mean loss of exact_time_int and the ability to redo Migration_DeprecateExactTimeInt. Probably should encourage SQLite users to backup before this migration.