Allow migrations to specify another migration they should run before. (Kind of like `dependencies` in reverse.)

[Morgan Wahl]

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.

[Marten Kenbeek]

​run_before? This feature always existed, but was recently documented I believe.