Setting DATABASES[alias]["TEST"]["MIGRATE"] = False should mean that `migrate` isn't run.

[Daniel Quinn]

We've been working on a project which uses Django heavily on the default database but also communicates with a number of other databases for other unmanaged data. For testing purposes, we have a custom test runner that dumps the external db schema into a local db and we then leverage Django's TestCase class and treat them like any other database: the expectation being that data inserted in a test will be rolled back at the end of the test. For the most part, this works reasonably well, though it's quite slow to start.

In digging into how I might improve the start-up speed, I realised that despite MIGRATE being set to False for all of these external databases, ​Django is still running `migrate` against these databases. This means that when the test run starts, Django writes our entire database schema to the default database and the three other external databases (albeit as a syncdb rather than running all migrations), only to be destroyed and overwritten with our own schemas.

It seems to me that if there's a flag called MIGRATE that you can set to False, that that would mean "don't run migrate for this database". If there's a compelling reason to still run migrate against all databases listed, it would be good then at least to mention in the docs that this is what's actually happening. Better still would be some pointers around how to work with an unmanaged database in tests.

[Mariusz Felisiak]

Thanks for the report.

It seems to me that if there's a flag called MIGRATE that you can set to False, that that would mean "don't run migrate for this database".

It's strictly documented how MIGRATE works: "When set to False, migrations won’t run when creating the test database. This is similar to setting None as a value in MIGRATION_MODULES, but for all apps.", more details can be found in MIGRATION_MODULES docs.

"migrations won’t run when creating the test database" it's not the same as "migrate command won't run".

If there's a compelling reason to still run migrate against all databases listed, it would be good then at least to mention in the docs that this is what's actually happening.

Yes it's see #32012 and 77caeaea888d1744416b213036ff29699758de76.

I don't think that your use case with a custom workflow and a custom TestCase is (or should be) supported by the MIGRATE setting. You can try to create a custom migrate command and skip apps without a migration module.

[Daniel Quinn]

I'm not sure I understand the reasoning above, but if the project considers this a wontfix, I'll find a way to roll with it.

Can I ask then, is there an officially sanctioned way to write a Django project that talks to external, unmanaged databases that will also allow you to write tests against local copies of those databases for integration tests? I had thought that setting MIGRATE=False was it, but as it is, simply having these databases in settings.DATABASES makes the test runner write to them, which is really not awesome.