#26377: Allow migrations to specify another migration they should run before.
(Kind
of like `dependencies` in reverse.)
-----------------------------+--------------------
Reporter: morganwahl | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------
Add support for another attribute of migrations similar to `dependencies`
that specifies other migrations this one must run before.
I have run into two different situations where this was needed:
- A model changes the type of it's primary key (possibly MySQL specific).
If I have an app with a foreign key to a model in another app and that
other app changes the type of the primary key of that model (e.g. from
integer to string), before I can run the other app's migration that change
the type I first have to remove the FK constraint on my model, or else the
other migration will fail. (And then I need to add the constraint back,
but that can be handled correctly with the `dependencies` attribute.) To
ensure the migrations are run in the correct order, I need a way to say
the one that removes the constraint has to run before the one that change
the PK type. This is particularly true when the other app is not mine, but
some package that I just use.
- An app has a proxy model to one of it's own apps, but then decides to
merge the proxy model into the model it subclassed. This is pretty much a
no-op from the database's standpoint, _except_ for ContentTypes. If
another app depends on the one with the proxy, and has a FK to
ContentType, it needs to update the rows with FKs to the proxy's
ContentType to be FKs to the base model's ContentType instead. This should
run _before_ the datamigration in the proxy model's app that removes the
ContentType, to prevent deletes cascading (or setting null or raising an
exception, as the case may be).
The common theme of both these situations is: an upstream model you depend
on changes something that requires a migration of your models that must
run before one of their migrations.
I'm not sure how complicated this would be to implement, but it seems
feasible.
--
Ticket URL: <https://code.djangoproject.com/ticket/26377>
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/053.e9888f89ca821c5ae88f496f1dce9ccf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
