fix: reorder subject index migration to be MySQL FK-safe (production hotfix) - #31
Conversation
The AddSubjectNameUniqueIndex migration dropped IX_Subjects_UserId before creating its replacement. On MySQL that index is the sole backing for FK_Subjects_Users_UserId, so the DROP is rejected and db.Database.Migrate() crashes at startup (production outage). Reorder Up() so the FK always has a backing index: alter the Name collation, create the composite unique IX_Subjects_UserId_Name (whose leading UserId column can serve the FK), and only then drop the old single-column index. Down() reverses in the mirror-safe order. No schema-shape change versus the previous migration intent; only the statement order differs. The original migration failed on its first statement, so it was never recorded in __EFMigrationsHistory and the corrected version applies cleanly on the next deploy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA single EF Core migration file is updated to fix the operation sequence for MySQL compatibility. In ChangesMigration Operation Reorder
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Production hotfix
db.Database.Migrate()crashes at startup with:Root cause
The
AddSubjectNameUniqueIndexmigration droppedIX_Subjects_UserIdbefore creating its replacement. On MySQL that index is the sole backing forFK_Subjects_Users_UserId, so theDROP INDEXis rejected and the wholeMigrate()call throws on boot.CI didn't catch it because the test suite uses the in-memory provider, which ignores relational migrations.
Fix
Reorder
Up()so the FK always has a backing index at every step:AlterColumn— set theNamecollation (utf8mb4_general_ci)CreateIndex— composite uniqueIX_Subjects_UserId_Name(leadingUserIdcan serve the FK)DropIndex— drop the old single-columnIX_Subjects_UserIdDown()reverses in the mirror-safe order (recreate single-column index → drop composite → revert collation).Why this is safe to deploy
The original migration failed on its first statement (the drop), so nothing was applied and it was never recorded in
__EFMigrationsHistory. The corrected migration runs from scratch on the next deploy and applies cleanly. No schema-shape change versus the original intent — only statement order differs.Testing
dotnet build -c Release— green, 0 warnings.🤖 Generated with Claude Code
Summary by CodeRabbit