#35508: Add an --ignore-deps flag to squashmigrations
-------------------------------------+-------------------------------------
Reporter: Shai | Owner: nobody
Berger |
Type: New | Status: new
feature |
Component: | Version: dev
Migrations | Keywords: squash
Severity: Normal | squashmigrations
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 1 | Needs tests: 1
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
In large, long-going projects -- the ones whose need for migration
squashing is the greatest -- apps have a tendency to develop dependencies
upon each other. This entails problems with migrations -- dependencies
could be circular, or an app could be removed from the project but the
migrations that hold dependencies on it still remain, and
{{{squashmigrations}}} faces constraints that makes it very hard to do
correctly. Current implementation often generates migrations that make no
sense, with dependencies on several migrations from the same app.
As a partial solution, let's add a {{{--ignore-deps}}} flag to
{{{squashmigrations}}}. When this flag is applied, the generated squashed
migration will
- Only depend on the dependencies of the first migration in the range
squashed
- Not include the operations that create or modify relation fields, if
these fields refer to models from other apps (deletion can be included)
The idea is that such a migration will be correct, but not complete.
Assuming the range of migrations includes the last migrations of the app,
it will then be possible to add the missing pieces by a regular
{{{makemigrations}}}; but the squashing will still include all the non-
ellidable {{{RunSQL}}} and {{{RunPython}}} operations -- the
{{{squashmigrations --ignore-deps}}} + {{{makemigrations}}} dance is
proposed as a safer alternative to "migration bankruptcy", the practice of
just removing all the migrations and stating afresh
On a side note: It may be safer to add an operation which enforces that it
is indeed called with the last migration of the app in range, and maybe
even automatically invokes the following {{{makemigrations}}}, but I think
we should trust developers with the lower-level building bricks, which may
be useful in other situations as well.
This follows from a [https://forum.djangoproject.com/t/idea-make-squash-
migrations-no-deps/23986 discussion on the forum].
--
Ticket URL: <https://code.djangoproject.com/ticket/35508>
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 on the web visit
https://groups.google.com/d/msgid/django-updates/0107018ff81ec493-f7a35ea7-35a3-470e-bc7f-5a4b314682c7-000000%40eu-central-1.amazonses.com.
