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
22834	The builtin migrations being the only way to do migrations breaks data migrations/fixtures in tests	gc@…	nobody	"The docs say:


When you run ./manage.py test, Django looks at the TEST_RUNNER setting to determine what to do. By default, TEST_RUNNER points to 'django.test.runner.DiscoverRunner'. This class defines the default Django testing behavior. This behavior involves:

Performing global pre-test setup.
Looking for tests in any file below the current directory whose name matches the pattern test*.py.
Creating the test databases.
'''Running migrate to install models and initial data into the test databases.'''
Running the tests that were found.
Destroying the test databases.
Performing global post-test teardown.

This is not true. There is no way to have initial data in the database for testing. The process of creating the test database also flushes it. Previously, a common pattern was to have initial data in south migrations and this worked, since south came later. Now, it is impossible to have initial data for tests, without test fixtures.

This is not documented in initial data, it says you can't use custom SQL for tests, but then it says you should use fixtures for tests, even though fixtures are deprecated for production use, which is... well, weird. Additionally, you cannot use data migrations, since those will be flushed as well.

Finally, looking at the code: https://github.com/django/django/blob/stable/1.7.x/django/db/backends/creation.py#L376

I don't understand how this could work, since people that have transactions are now screwed, vs no transaction.
"	Uncategorized	closed	Migrations	1.7-beta-2	Normal	duplicate			Unreviewed	0	0	0	0	0	0