The builtin migrations being the only way to do migrations breaks data migrations/fixtures in tests

[gc@…]

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.

[Tim Graham]

I think this is a duplicate of #22487 which was resolved just a couple days before your report so perhaps you didn't see it. Could you confirm?

That said, I believe we still need to update the documentation as you noted.

[anonymous]

I think that's a terrible solution, though. :-( The simple solution would be to have an argument for tests, that makes it not flush. We worked around by defining our own flush that does nothing, but that's an ugly hack.

Additionally, the solution is not only slow and ugly, but broken since it makes you force no transactions (no idea what the other implications of this are)

[Aymeric Augustin]

Thanks for the kind words. I gather from your comment that the issue you reported is fixed, even though you disagree with the fix.

I'm not sure what the issue with transactions is. Since it's a different one, it belongs to a separate ticket. I'll need a bit more information to understand it.

Finally, if you can provide a better and simpler solution that still meets all the constraints discussed in #22487, including the mailing-list thread linked to in the first comment, please open a new ticket and submit a patch or a pull request! Thank you.