Opened 8 years ago
Closed 8 years ago
#27155 closed Cleanup/optimization (wontfix)
makemigrations --no-check-consistency command line argument
Reported by: | Sjoerd Job Postmus | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.10 |
Severity: | Normal | Keywords: | makemigrations, check_consistent_history |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There are a number of edge-cases for makemigrations where it fails in 1.10 while it did not fail in 1.9.
To quote Tim Graham in #27142:
I'm beginning to think that makemigrations shouldn't have this check in the first place due to the many issues that have been reported (#27054, #27110, #27141) and the more and more complexity that seems needed to add to fix it. Other opinions welcome. In my view, the most natural thing to do after creating a migration is to apply it, so it doesn't seem like delaying the check from makemigrations to migrate would have a huge drawback.
I propose that we add a command line argument --no-check-consistent-history
(or something similar, bikeshed away!) which skips the calls to check_consistent_history
.
To me it seems like this should be possible to add in the next release and takes the pressure off fixing the corner-cases a bit to make sure we can come up with a good solution.
Change History (1)
comment:1 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Type: | Uncategorized → Cleanup/optimization |
It's a non-trivial amount of work to add and documentation a new option and then to deprecate it if we fix things later, so I'm not in favor. If it's truly a blocker for a project, a workaround is to add your own
makemigrations
command without the consistency check, so the issue is really not that critical.