diff -r d2539f0cf49c django/core/management/commands/syncdb.py
a
|
b
|
|
26 | 26 | interactive = options.get('interactive') |
27 | 27 | show_traceback = options.get('traceback', False) |
28 | 28 | |
| 29 | # Stealth option -- 'load_initial_data' is used by the testing setup |
| 30 | # process to disable initial fixture loading. |
| 31 | load_initial_data = options.get('load_initial_data', True) |
| 32 | |
29 | 33 | self.style = no_style() |
30 | 34 | |
31 | 35 | # Import the 'management' module within each installed app, to register |
… |
… |
|
154 | 158 | else: |
155 | 159 | transaction.commit_unless_managed(using=db) |
156 | 160 | |
157 | | from django.core.management import call_command |
158 | | call_command('loaddata', 'initial_data', verbosity=verbosity, database=db) |
| 161 | # Load initial_data fixtures (unless that has been disabled) |
| 162 | if load_initial_data: |
| 163 | from django.core.management import call_command |
| 164 | call_command('loaddata', 'initial_data', verbosity=verbosity, database=db) |
diff -r d2539f0cf49c django/db/backends/creation.py
a
|
b
|
|
359 | 359 | # Report syncdb messages at one level lower than that requested. |
360 | 360 | # This ensures we don't get flooded with messages during testing |
361 | 361 | # (unless you really ask to be flooded) |
362 | | call_command('syncdb', verbosity=max(verbosity - 1, 0), interactive=False, database=self.connection.alias) |
| 362 | call_command('syncdb', |
| 363 | verbosity=max(verbosity - 1, 0), |
| 364 | interactive=False, |
| 365 | database=self.connection.alias, |
| 366 | load_initial_data=False) |
| 367 | |
| 368 | # We need to then do a flush to ensure that any data installed by |
| 369 | # custom SQL has been removed. The only test data should come from |
| 370 | # test fixtures, or autogenerated from post_syncdb triggers. |
| 371 | # This has the side effect of loading initial data (which was |
| 372 | # intentionally skipped in the syncdb). |
| 373 | call_command('flush', |
| 374 | verbosity=max(verbosity - 1, 0), |
| 375 | interactive=False, |
| 376 | database=self.connection.alias) |
363 | 377 | |
364 | 378 | from django.core.cache import get_cache |
365 | 379 | from django.core.cache.backends.db import BaseDatabaseCache |
diff -r d2539f0cf49c docs/howto/initial-data.txt
a
|
b
|
|
121 | 121 | that, by the time your custom data files are executed, all the |
122 | 122 | database tables already will have been created. |
123 | 123 | |
| 124 | .. admonition:: Initial SQL data and testing |
| 125 | |
| 126 | This technique *cannot* be used to provide initial data for |
| 127 | testing purposes. Django's test framework flushes the contents of |
| 128 | the test database after each test; as a result, any data added |
| 129 | using the custom SQL hook will be lost. |
| 130 | |
| 131 | If you require data for a test case, you should add it using |
| 132 | either a :ref:`test fixture <topics-testing-fixtures>`, or |
| 133 | programatically add it during the ``setUp()`` of your test case. |
| 134 | |
124 | 135 | Database-backend-specific SQL data |
125 | 136 | ---------------------------------- |
126 | 137 | |
diff -r d2539f0cf49c docs/topics/testing.txt
a
|
b
|
|
1237 | 1237 | Fixtures with other names can always be installed manually using |
1238 | 1238 | the :djadmin:`manage.py loaddata<loaddata>` command. |
1239 | 1239 | |
| 1240 | .. admonition:: Initial SQL data and testing |
| 1241 | |
| 1242 | Django provides a second way to insert initial data into models -- |
| 1243 | the :ref:`custom SQL hook <initial-sql>`. However, this technique |
| 1244 | *cannot* be used to provide initial data for testing purposes. |
| 1245 | Django's test framework flushes the contents of the test database |
| 1246 | after each test; as a result, any data added using the custom SQL |
| 1247 | hook will be lost. |
| 1248 | |
1240 | 1249 | Once you've created a fixture and placed it in a ``fixtures`` directory in one |
1241 | 1250 | of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by |
1242 | 1251 | specifying a ``fixtures`` class attribute on your :class:`django.test.TestCase` |
diff -r d2539f0cf49c tests/regressiontests/initial_sql_regress/models.py
a
|
b
|
|
7 | 7 | class Simple(models.Model): |
8 | 8 | name = models.CharField(max_length = 50) |
9 | 9 | |
10 | | # NOTE: The format of the included SQL file for this test suite is important. |
11 | | # It must end with a trailing newline in order to test the fix for #2161. |
diff -r d2539f0cf49c tests/regressiontests/initial_sql_regress/tests.py
a
|
b
|
|
5 | 5 | |
6 | 6 | class InitialSQLTests(TestCase): |
7 | 7 | def test_initial_sql(self): |
8 | | self.assertEqual(Simple.objects.count(), 7) |
| 8 | # The format of the included SQL file for this test suite is important. |
| 9 | # It must end with a trailing newline in order to test the fix for #2161. |
| 10 | |
| 11 | # However, as pointed out by #14661, test data loaded by custom SQL |
| 12 | # can't be relied upon; as a result, the test framework flushes the |
| 13 | # data contents before every test. This test validates that this has |
| 14 | # occurred. |
| 15 | self.assertEqual(Simple.objects.count(), 0) |