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) |