#28784 closed Cleanup/optimization (fixed)
Clarify migrate --fake documentation
Reported by: | Ramez Kabbani | Owned by: | Senthil |
---|---|---|---|
Component: | Documentation | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
migrate documentation implies that running migrate --fake on a specific migration toggles its applied status (applied => unapplied and vice versa). The reality is that one needs to run migrate --fake on the preceding migration to mark the migration as unapplied.
Change History (8)
comment:1 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|
follow-up: 4 comment:2 by , 7 years ago
What about:
Tells Django to mark the migrations before and including this <migrationname> as having been applied, meanwhile mark the migrations after this <migrationname> as having been unapplied?
But it is not concise.
comment:3 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 7 years ago
Replying to tothegump:
What about:
Tells Django to mark the migrations before and including this <migrationname> as having been applied, meanwhile mark the migrations after this <migrationname> as having been unapplied?
But it is not concise.
What about:
Tells Django to mark the migrations up to the target one (following the rules described above) as applied, but without actually running the SQL to change your database schema.
IMO the source of confusion could be the or unnaplied
in the description. But after having read the behavior rules above for the second argument and the meaning of the word fake
itself I believe it is pretty clear.
comment:5 by , 7 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Agreed it could be clearer.