Author: russellm
Date: 2011-01-18 10:55:00 -0600 (Tue, 18 Jan 2011)
New Revision: 15241
Added:
django/branches/releases/1.2.X/docs/releases/1.2.5.txt
Modified:
django/branches/releases/1.2.X/django/core/management/commands/syncdb.py
django/branches/releases/1.2.X/docs/howto/initial-data.txt
django/branches/releases/1.2.X/docs/releases/index.txt
django/branches/releases/1.2.X/docs/topics/testing.txt
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/models.py
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/tests.py
Log:
[1.2.X] Refs #14661 -- Clarified the handling of initial data injected 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.
Modified:
django/branches/releases/1.2.X/django/core/management/commands/syncdb.py
===================================================================
--- django/branches/releases/1.2.X/django/core/management/commands/syncdb.py
2011-01-18 16:54:28 UTC (rev 15240)
+++ django/branches/releases/1.2.X/django/core/management/commands/syncdb.py
2011-01-18 16:55:00 UTC (rev 15241)
@@ -26,6 +26,10 @@
interactive = options.get('interactive')
show_traceback = options.get('traceback', False)
+ # Stealth option -- 'load_initial_data' is used by the testing setup
+ # process to disable initial fixture loading.
+ load_initial_data = options.get('load_initial_data', True)
+
self.style = no_style()
# Import the 'management' module within each installed app, to register
@@ -148,5 +152,7 @@
else:
transaction.commit_unless_managed(using=db)
- from django.core.management import call_command
- call_command('loaddata', 'initial_data', verbosity=verbosity,
database=db)
+ # Load initial_data fixtures (unless that has been disabled)
+ if load_initial_data:
+ from django.core.management import call_command
+ call_command('loaddata', 'initial_data', verbosity=verbosity,
database=db)
Modified: django/branches/releases/1.2.X/docs/howto/initial-data.txt
===================================================================
--- django/branches/releases/1.2.X/docs/howto/initial-data.txt 2011-01-18
16:54:28 UTC (rev 15240)
+++ django/branches/releases/1.2.X/docs/howto/initial-data.txt 2011-01-18
16:55:00 UTC (rev 15241)
@@ -121,6 +121,17 @@
that, by the time your custom data files are executed, all the
database tables already will have been created.
+.. admonition:: Initial SQL data and testing
+
+ This technique *cannot* be used to provide initial data for
+ testing purposes. Django's test framework flushes the contents of
+ the test database after each test; as a result, any data added
+ using the custom SQL hook will be lost.
+
+ If you require data for a test case, you should add it using
+ either a :ref:`test fixture <topics-testing-fixtures>`, or
+ programatically add it during the ``setUp()`` of your test case.
+
Database-backend-specific SQL data
----------------------------------
Added: django/branches/releases/1.2.X/docs/releases/1.2.5.txt
===================================================================
--- django/branches/releases/1.2.X/docs/releases/1.2.5.txt
(rev 0)
+++ django/branches/releases/1.2.X/docs/releases/1.2.5.txt 2011-01-18
16:55:00 UTC (rev 15241)
@@ -0,0 +1,46 @@
+==========================
+Django 1.2.5 release notes
+==========================
+
+Welcome to Django 1.2.5!
+
+This is the fifth "bugfix" release in the Django 1.2 series,
+improving the stability and performance of the Django 1.2 codebase.
+
+With one exception, Django 1.2.5 maintains backwards compatibility
+with Django 1.2.4, but contain a number of fixes and other
+improvements. Django 1.2.5 is a recommended upgrade for any
+development or deployment currently using or targeting Django 1.2.
+
+For full details on the new features, backwards incompatibilities, and
+deprecated features in the 1.2 branch, see the :doc:`/releases/1.2`.
+
+One backwards incompatibility
+=============================
+
+Django provides a custom SQL hooks as a way to inject hand-crafted SQL
+into the database synchronization process. One of the possible uses
+for this custom SQL is to insert data into your database. If your
+custom SQL contains ``INSERT`` statements, those insertions will be
+performed every time your database is synchronized. This includes the
+synchronization of any test databases that are created when you run a
+test suite.
+
+However, in the process of testing the Django 1.3, it was discovered
+that this feature has never completely worked as advertised. When
+using database backends that don't support transactions, or when using
+a TransactionTestCase, data that has been inserted using custom SQL
+will not be visible during the testing process.
+
+Unfortunately, there was no way to rectify this problem without
+introducing a backwards incompatibility. Rather than leave
+SQL-inserted initial data in an uncertain state, Django now enforces
+the policy that data inserted by custom SQL will *not* be visible
+during testing.
+
+This change only affects the testing process. You can still use custom
+SQL to load data into your production database as part of the syncdb
+process. If you require data to exist during test conditions, you
+should either insert it using :ref:`test fixtures
+<topics-testing-fixtures>`, or using the ``setUp()`` method of your
+test case.
Modified: django/branches/releases/1.2.X/docs/releases/index.txt
===================================================================
--- django/branches/releases/1.2.X/docs/releases/index.txt 2011-01-18
16:54:28 UTC (rev 15240)
+++ django/branches/releases/1.2.X/docs/releases/index.txt 2011-01-18
16:55:00 UTC (rev 15241)
@@ -19,6 +19,7 @@
.. toctree::
:maxdepth: 1
+ 1.2.5
1.2.4
1.2.2
1.2
Modified: django/branches/releases/1.2.X/docs/topics/testing.txt
===================================================================
--- django/branches/releases/1.2.X/docs/topics/testing.txt 2011-01-18
16:54:28 UTC (rev 15240)
+++ django/branches/releases/1.2.X/docs/topics/testing.txt 2011-01-18
16:55:00 UTC (rev 15241)
@@ -1151,6 +1151,15 @@
Fixtures with other names can always be installed manually using
the :djadmin:`manage.py loaddata<loaddata>` command.
+.. admonition:: Initial SQL data and testing
+
+ Django provides a second way to insert initial data into models --
+ the :ref:`custom SQL hook <initial-sql>`. However, this technique
+ *cannot* be used to provide initial data for testing purposes.
+ Django's test framework flushes the contents of the test database
+ after each test; as a result, any data added using the custom SQL
+ hook will be lost.
+
Once you've created a fixture and placed it in a ``fixtures`` directory in one
of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by
specifying a ``fixtures`` class attribute on your :class:`django.test.TestCase`
Modified:
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/models.py
===================================================================
---
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/models.py
2011-01-18 16:54:28 UTC (rev 15240)
+++
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/models.py
2011-01-18 16:55:00 UTC (rev 15241)
@@ -7,5 +7,3 @@
class Simple(models.Model):
name = models.CharField(max_length = 50)
-# NOTE: The format of the included SQL file for this test suite is important.
-# It must end with a trailing newline in order to test the fix for #2161.
Modified:
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/tests.py
===================================================================
---
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/tests.py
2011-01-18 16:54:28 UTC (rev 15240)
+++
django/branches/releases/1.2.X/tests/regressiontests/initial_sql_regress/tests.py
2011-01-18 16:55:00 UTC (rev 15241)
@@ -5,4 +5,11 @@
class InitialSQLTests(TestCase):
def test_initial_sql(self):
- self.assertEqual(Simple.objects.count(), 7)
+ # The format of the included SQL file for this test suite is important.
+ # It must end with a trailing newline in order to test the fix for
#2161.
+
+ # However, as pointed out by #14661, test data loaded by custom SQL
+ # can't be relied upon; as a result, the test framework flushes the
+ # data contents before every test. This test validates that this has
+ # occurred.
+ self.assertEqual(Simple.objects.count(), 0)
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
