Do not suppress sqlmigrate errors
See original GitHub issueNow, if an error occurs while executing the sqlmigrate
command, then as a result, the analyzer will be given an empty string instead of migrations SQL. This can cause a backwards incompatible migration to get into production and break it.
The suggestion is to add a strict check option to require the sqlmigrate
command to be run for migration.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:6 (2 by maintainers)
Top Results From Across the Web
Django models sqlmigrate - too few arguments - Stack Overflow
I just ran across this, my issue: I'm making a lot of changes at once and I need to see all the migrations...
Read more >sql-migrate/migrate.go at master · rubenv/sql-migrate - GitHub
DisableCreateTable = disable. } // SetIgnoreUnknown sets the flag that skips database check to see if there is a. // migration in the...
Read more >Migrations - Django documentation
Migrations¶. Migrations are Django's way of propagating changes you make to your models (adding a field, deleting a model, etc.) into your database...
Read more >Django Migrations: A Primer - Real Python
Unapplying a migration does not remove its migration file. The next time you run the migrate command, the migration will be applied again....
Read more >MigrationWiz Errors - 401 Unauthorized Error Suite
Error Message This error can take several different forms. Some of the most common versions are listed below but not all versions are......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That’s a very interesting use case! Thanks for sharing that 😃
After a bit of reflection, this is definitely a case we want to avoid. We want the linter to be reliable, and I’d prefer it to be over cautious and warn the user that the migration could be problematic, but it can’t say for sure, than to silently consider the migration as valid. I’ll write a patch to change this, and this will probably mark the next major release for the linter 😃
First, just for the record (and so that I don’t forget it 😛) it’s a known bug in Django: https://code.djangoproject.com/ticket/26624.
But in short, I have a model like:
and create a migration. Then, if we change the
unique_together
and inverse the columns for instance (so that we need to drop and recreate the constraint) we have a new migrationThe
sqlmigrate
of this migration fails if the one creating theunique_together
was not applied (the error isValueError: Found wrong number (0) of constraints for app_remove_constraint_mymodel(x, y)
). But if we run the first migration, then thesqlmigrate
gives us:So the issue is that, on a project where all migrations are linted but not applied (maybe on a CI build), there is a high change that at least one migration will fail like this I think.
I would actually also lean towards option (1), as it is the option where the linter is doing the least “magic”. So letting, by default, the error raise but with a specific message from the linter giving some indications what to do could be viable in my opinion 🤔 But giving an easy possibility to ignore this migration (and more or less fallback on the previous behaviour).