id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
33177	"Setting DATABASES[alias][""TEST""][""MIGRATE""] = False should mean that `migrate` isn't run."	Daniel Quinn	nobody	"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, [https://github.com/django/django/blob/28f66b2783e52d5be51887c31cd2be907b820e11/django/db/backends/base/creation.py 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."	New feature	closed	Testing framework	dev	Normal	wontfix			Unreviewed	0	0	0	0	0	0