Opened 5 years ago
Closed 5 years ago
#31504 closed New feature (fixed)
Allow makemigrations to skip database consistency checks
Reported by: | Tom Forbes | Owned by: | wtkm11 |
---|---|---|---|
Component: | Migrations | Version: | 3.0 |
Severity: | Normal | Keywords: | |
Cc: | Ian Bottomley | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
Currently makemigrations always requires an active database connection, due to it executing loader.check_consistent_history()
here: https://github.com/django/django/blob/290d8471bba35980f3e228f9c171afc40f2550fa/django/core/management/commands/makemigrations.py#L93-L101
Sometimes you are making a change on a machine that doesn't have a database set up or is configured to use a database on a host that isn't resolvable (i.e a postgres
host that's only resolvable within docker-compose). If you run makemigrations
on such a machine it will fail while attempting to check the migrations consistency, which is quite annoying. The solution seems to either add a django.db.backends.dummy
backend for such cases or start a database server locally.
I'd like to add a flag to skip the consistency check in these situations, or fail gracefully if the connection to the database isn't available.
Change History (12)
comment:1 by , 5 years ago
Cc: | added |
---|
comment:2 by , 5 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 5 years ago
I added the --skip-consistency-check flag to allow skipping the inconsistent migration history check in the makemigrations command along with a unit test in tests.migrations.test_commands::MakeMigrationsTests.
comment:6 by , 5 years ago
I've been thinking more about this - wouldn't it be preferable to gracefully fail if the check_consistent_history()
method fails due to a connection error? Not sure what anyone else thinks, but your MR looks simple enough. Just make sure you add something to the release notes + documentation.
comment:7 by , 5 years ago
Patch needs improvement: | set |
---|
I agree with Tom, this is quite niche so I would also prefer to fail gracefully. IMO we don't need a new option.
comment:8 by , 5 years ago
I updated the PR so that a CommandError describing the error that was encountered in check_consistent_history will be raised.
comment:9 by , 5 years ago
Patch needs improvement: | unset |
---|
comment:10 by , 5 years ago
I just updated the PR again so that a warning describing the error that was encountered in check_consistent_history will be issued (and the command will be able to continue).
comment:11 by , 5 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
OK, this seems reasonable to me. (Others can shout if I missed something. :)