#28250: migration depending on non-existing legacy migration
-------------------------------+--------------------------------------
Reporter: Brian May | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by Aymeric Augustin):
1.7 introduced the new migration system but still supported apps without
migrations. This possibility must have been removed in 1.9 (I didn't
check) given that we hadn't tied the deprecation schedule to LTS releases
yet. This means the missing migration must be created and fake-applied on
Django < 1.9 before moving on to later versions of Django.
If I read the Debian bug correctly, going through 1.7 => 1.8 => 1.10 and
running `migrate` at each step works. Somewhere in the middle of the
thread, it says: "1.10 requires it and it's code in 1.8 that handles the
transition." This is consistent with my hypothesis.
We've always suggested that users should go through every x.y version when
upgrading. We considered documenting LTS to LTS upgrades but didn't do it
because we didn't feel it would be very different from concatenating the
release notes for each intermediary version; we haven't heard much
specific feedback in this area.
Non-LTS to non-LTS across three versions is not a scenario we're trying to
support and also like not a scenario for which we can reasonably provide
adequate guarantees (unless someone's willing to back that with a fat
check). The combination matrix of such upgrades is awful.
In this particular case, it doesn't help 1.7 wasn't the most polished
release, because it contained both the migrations framework and the app
loading refactor. Going through 1.8 LTS is strongly recommended.
----
Coming back to the original bug report, I agree with Claude's
recommendation.
You must only do this if the tables were created by a previous version, or
else a fresh install of the most recent version of the package will fail.
IMO the logic should be: check if a table created on Django 1.7 already
exists in the database but there's no corresponding row in the
django_migrations table (this means you're hitting the problematic upgrade
path), and in that case create a suitable row in the django_migrations
table to fake-apply the migration. This can be done in SQL directly.
I believe this is stretching the limits of what's reasonable to do with a
package manager.
--
Ticket URL: <https://code.djangoproject.com/ticket/28250#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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.414fa5db552b0caa14899ebca62daa3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
