Migrations should only be marked as run on "their" db

[Simon Percivall]

We're using a multi database setup. Each db will have all migrations written to the "django_migrations" table, even if the migration doesn't apply to that db. Also, state is calculated for each migration, even when, again, that migration doesn't apply.

It'd (for the writing of migrations to the db) be less confusing and cleaner to write only applicable migrations to "django_migrations". And it would be faster if state were to be calculated only when necessary. As it is, building up state for all models takes a considerable amount of time when running migrations on a "non-default" database where we only have a few tables.

[Marten Kenbeek]

Hi Simon,

With the way things work now, we don't know if a migration has to be applied to a specific database, we only know if an operation applies to a database. Furthermore, the router that determines this depends on the current state of the model at that point in the migrations. In most cases it won't matter which historical state is passed, but because we pass that specific state (and need to, to maintain backwards compatibility), it is not trivial to know if a migration needs to run on a specific database.

Quite a few optimizations have made it to 1.8, and we will continue to optimize it (1.8.1 introduces a massive improvement in model state rendering). If you have a lot of migrations, squashing them will also help to speed things up considerably.

Your proposal makes sense, but I think it will require a substantial amount of work. I might underestimate the amount of multi-db setups, but I don't think it's worth it at the moment. I also think there are still some significant improvements to be made to the general case. If this is a major point for you, you are of course more than welcome to work on it.