#36643: Migrate should not check for consistent history when faking migrations
-----------------------------------+--------------------------------------
Reporter: Alexandru Chirila | Owner: (none)
Type: Bug | Status: new
Component: Migrations | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-----------------------------------+--------------------------------------
Comment (by Alexandru Chirila):
Replying to [comment:1 Andrew Williamson]:
> Hi, I'm struggling to think of the scenario where you'd fake a migration
over an inconsistent history, and it'd leave a consistent state that you'd
not need to fake the next time. I.e. it'd always be inconsistent, every
time. Can you provide an example of where this would help?
Sure, here's what happend to me:
- I had some squashed migrations for some of the django apps in my
project.
- I had **incorrectly** verified that all instances have indeed been
updated to the squashed migrations
- Considering I thought all instances were updated, I removed the old
migrations from the code.
- When I updated the one instance that did NOT received the squashed
migrations before, the `manage.py migrate` command was run automatically
- One of the apps did not have any squashed migrations, so it remained
marked as applied and appeared updated (i.e. `shortner` in this case)
- The same app `shortner` also was depending on a another app `charts`
that has had squashed migration, and as far as Django is concerned it
looked like none of the migrations of applied for `charts` but all
migrations were applied to `shortner`. Because the when the migrate script
ran it marked all migrations as being unapplied for `charts`.
- The consistency check was seeing that migrations for `shortner` were
applied before `charts`. Even though both apps were up to date will all
the schema changes.
----
Beeing in this scenario, I thought that: "Hey no problem, the DB itself is
up to date. Django has this 'fake' apply migration utility just to bail
you out when you mess up massively as I did."
Well, apparently I could not be bailed out from this scenario by the "fake
apply" migration because of this "consistency check". So I ended up
messing around directly into django internal tables (which I would rather
always avoid) to fix my issue because the "migrate" command refused to do
anything at all.
----
Definetly this was a big user error on my part, combined with an
unfortunate set of circumstances. That said, I don't think that there is
any good reason to perform a consistency check when running the "fake
apply", since presumably you are in weird state anyway and you're using
the "fake apply" to fix something that was caused by some manual error.
If there is a good reason to run the check in this scenario as well, a
simple flag that allows you to disable it would be useful I think. I did
try "--skip-checks" but that doesn't work as far as I can tell.
--
Ticket URL: <https://code.djangoproject.com/ticket/36643#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/01070199c4029c7d-fd48a778-d906-484c-80a8-65aae862e0d1-000000%40eu-central-1.amazonses.com.
