Ticket #14661: t14661a.diff

File t14661a.diff, 5.6 KB (added by Russell Keith-Magee, 13 years ago)

Proposed fix for the initial_data test problem

  • django/core/management/commands/syncdb.py

    diff -r d2539f0cf49c django/core/management/commands/syncdb.py
    a b  
    2626        interactive = options.get('interactive')
    2727        show_traceback = options.get('traceback', False)
    2828
     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
    2933        self.style = no_style()
    3034
    3135        # Import the 'management' module within each installed app, to register
     
    154158                        else:
    155159                            transaction.commit_unless_managed(using=db)
    156160
    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)
  • django/db/backends/creation.py

    diff -r d2539f0cf49c django/db/backends/creation.py
    a b  
    359359        # Report syncdb messages at one level lower than that requested.
    360360        # This ensures we don't get flooded with messages during testing
    361361        # (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)
    363377
    364378        from django.core.cache import get_cache
    365379        from django.core.cache.backends.db import BaseDatabaseCache
  • docs/howto/initial-data.txt

    diff -r d2539f0cf49c docs/howto/initial-data.txt
    a b  
    121121that, by the time your custom data files are executed, all the
    122122database tables already will have been created.
    123123
     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
    124135Database-backend-specific SQL data
    125136----------------------------------
    126137
  • docs/topics/testing.txt

    diff -r d2539f0cf49c docs/topics/testing.txt
    a b  
    12371237    Fixtures with other names can always be installed manually using
    12381238    the :djadmin:`manage.py loaddata<loaddata>` command.
    12391239
     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
    12401249Once you've created a fixture and placed it in a ``fixtures`` directory in one
    12411250of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by
    12421251specifying a ``fixtures`` class attribute on your :class:`django.test.TestCase`
  • tests/regressiontests/initial_sql_regress/models.py

    diff -r d2539f0cf49c tests/regressiontests/initial_sql_regress/models.py
    a b  
    77class Simple(models.Model):
    88    name = models.CharField(max_length = 50)
    99
    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.
  • tests/regressiontests/initial_sql_regress/tests.py

    diff -r d2539f0cf49c tests/regressiontests/initial_sql_regress/tests.py
    a b  
    55
    66class InitialSQLTests(TestCase):
    77    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)
Back to Top