Add option to depend on current state

[klaas@…]

There is a certain error scenario that I run into too often: when developing I add a number of migrations and run each one after creating it without any problems.

However, when running the migrations on another dev machine or on production things start to fail. Reason: the fact that the various apps and their migrations depend on each other was not made explicit during development. This mistake was not revealed because they were run one-by-one on development (the usual state of affairs, since as a developer you're likely to want feedback on your code by running it)

My solution would be to add a parameter to schemamigration/datamigration that adds dependencies for the last migration of all other installed apps. This way migrations are guaranteed to be run in the same order on production as on development.

I imagine that in many cases this is *not* what you want; since it ties in your migrations with all your installed apps. However, if your apps are not-for-reuse and are simply parts of a single project this is exactly what you want.

I'm also open to other solutions since this one will probably generate a lot of cruft. But I do think the fact that migrations are generally not run in a particular order leads to too many problems.

[andrew]

Yeah, this is never going to be the solution - even for not-for-reuse apps this will go wrong as soon as you start to introduce third-party apps in for extra functionality, and it would be entirely useless (and even dangerous to use) to a large majority of our users.

My preferred solution is more like #509 - automatic dependencies based on foreign keys - which will essentially get what you want (things not failing horribly in production). I'm working on a solution which involves that at the moment, in fact.