Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

[1.2.X] Refs #14661 -- Clarified the handling of initial data injecte…

…d via custom SQL.

This is BACKWARDS INCOMPATIBLE CHANGE for anyone relying on SQL-injected initial data in a test case.

Backport of r15239 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@15241 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 0958f32209d680ae8002852b62c560e04bc09118 1 parent 86239cb
Russell Keith-Magee authored January 18, 2011
10  django/core/management/commands/syncdb.py
@@ -26,6 +26,10 @@ def handle_noargs(self, **options):
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
@@ -148,5 +152,7 @@ def model_installed(model):
148 152
                         else:
149 153
                             transaction.commit_unless_managed(using=db)
150 154
 
151  
-        from django.core.management import call_command
152  
-        call_command('loaddata', 'initial_data', verbosity=verbosity, database=db)
  155
+        # Load initial_data fixtures (unless that has been disabled)
  156
+        if load_initial_data:
  157
+            from django.core.management import call_command
  158
+            call_command('loaddata', 'initial_data', verbosity=verbosity, database=db)
11  docs/howto/initial-data.txt
@@ -121,6 +121,17 @@ the order in which they're executed. The only thing you can assume is
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
 
46  docs/releases/1.2.5.txt
... ...
@@ -0,0 +1,46 @@
  1
+==========================
  2
+Django 1.2.5 release notes
  3
+==========================
  4
+
  5
+Welcome to Django 1.2.5!
  6
+
  7
+This is the fifth "bugfix" release in the Django 1.2 series,
  8
+improving the stability and performance of the Django 1.2 codebase.
  9
+
  10
+With one exception, Django 1.2.5 maintains backwards compatibility
  11
+with Django 1.2.4, but contain a number of fixes and other
  12
+improvements. Django 1.2.5 is a recommended upgrade for any
  13
+development or deployment currently using or targeting Django 1.2.
  14
+
  15
+For full details on the new features, backwards incompatibilities, and
  16
+deprecated features in the 1.2 branch, see the :doc:`/releases/1.2`.
  17
+
  18
+One backwards incompatibility
  19
+=============================
  20
+
  21
+Django provides a custom SQL hooks as a way to inject hand-crafted SQL
  22
+into the database synchronization process. One of the possible uses
  23
+for this custom SQL is to insert data into your database. If your
  24
+custom SQL contains ``INSERT`` statements, those insertions will be
  25
+performed every time your database is synchronized. This includes the
  26
+synchronization of any test databases that are created when you run a
  27
+test suite.
  28
+
  29
+However, in the process of testing the Django 1.3, it was discovered
  30
+that this feature has never completely worked as advertised. When
  31
+using database backends that don't support transactions, or when using
  32
+a TransactionTestCase, data that has been inserted using custom SQL
  33
+will not be visible during the testing process.
  34
+
  35
+Unfortunately, there was no way to rectify this problem without
  36
+introducing a backwards incompatibility. Rather than leave
  37
+SQL-inserted initial data in an uncertain state, Django now enforces
  38
+the policy that data inserted by custom SQL will *not* be visible
  39
+during testing.
  40
+
  41
+This change only affects the testing process. You can still use custom
  42
+SQL to load data into your production database as part of the syncdb
  43
+process. If you require data to exist during test conditions, you
  44
+should either insert it using :ref:`test fixtures
  45
+<topics-testing-fixtures>`, or using the ``setUp()`` method of your
  46
+test case.
1  docs/releases/index.txt
@@ -19,6 +19,7 @@ Final releases
19 19
 .. toctree::
20 20
    :maxdepth: 1
21 21
 
  22
+   1.2.5
22 23
    1.2.4
23 24
    1.2.2
24 25
    1.2
9  docs/topics/testing.txt
@@ -1151,6 +1151,15 @@ documentation<dumpdata>` for more details.
1151 1151
     Fixtures with other names can always be installed manually using
1152 1152
     the :djadmin:`manage.py loaddata<loaddata>` command.
1153 1153
 
  1154
+.. admonition:: Initial SQL data and testing
  1155
+
  1156
+    Django provides a second way to insert initial data into models --
  1157
+    the :ref:`custom SQL hook <initial-sql>`. However, this technique
  1158
+    *cannot* be used to provide initial data for testing purposes.
  1159
+    Django's test framework flushes the contents of the test database
  1160
+    after each test; as a result, any data added using the custom SQL
  1161
+    hook will be lost.
  1162
+
1154 1163
 Once you've created a fixture and placed it in a ``fixtures`` directory in one
1155 1164
 of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by
1156 1165
 specifying a ``fixtures`` class attribute on your :class:`django.test.TestCase`
2  tests/regressiontests/initial_sql_regress/models.py
@@ -7,5 +7,3 @@
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.
9  tests/regressiontests/initial_sql_regress/tests.py
@@ -5,4 +5,11 @@
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)

0 notes on commit 0958f32

Please sign in to comment.
Something went wrong with that request. Please try again.