Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Copied in-development 1.2.5 release notes to trunk.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15323 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 8151c0431ecdd6aa0b41d6f19d5f7a696ac59aa7 1 parent 00e7a57
Carl Meyer authored January 26, 2011
63  docs/releases/1.2.5.txt
... ...
@@ -0,0 +1,63 @@
  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 two exceptions, 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
+Backwards incompatible changes
  19
+==============================
  20
+
  21
+FileField no longer deletes files
  22
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  23
+
  24
+In earlier Django versions, when a model instance containing a
  25
+:class:`~django.db.models.FileField` was deleted,
  26
+:class:`~django.db.models.FileField` took it upon itself to also delete the
  27
+file from the backend storage. This opened the door to several potentially
  28
+serious data-loss scenarios, including rolled-back transactions and fields on
  29
+different models referencing the same file. In Django 1.2.5,
  30
+:class:`~django.db.models.FileField` will never delete files from the backend
  31
+storage. If you need cleanup of orphaned files, you'll need to handle it
  32
+yourself (for instance, with a custom management command that can be run
  33
+manually or scheduled to run periodically via e.g. cron).
  34
+
  35
+Use of custom SQL to load initial data in tests
  36
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  37
+
  38
+Django provides a custom SQL hooks as a way to inject hand-crafted SQL
  39
+into the database synchronization process. One of the possible uses
  40
+for this custom SQL is to insert data into your database. If your
  41
+custom SQL contains ``INSERT`` statements, those insertions will be
  42
+performed every time your database is synchronized. This includes the
  43
+synchronization of any test databases that are created when you run a
  44
+test suite.
  45
+
  46
+However, in the process of testing the Django 1.3, it was discovered
  47
+that this feature has never completely worked as advertised. When
  48
+using database backends that don't support transactions, or when using
  49
+a TransactionTestCase, data that has been inserted using custom SQL
  50
+will not be visible during the testing process.
  51
+
  52
+Unfortunately, there was no way to rectify this problem without
  53
+introducing a backwards incompatibility. Rather than leave
  54
+SQL-inserted initial data in an uncertain state, Django now enforces
  55
+the policy that data inserted by custom SQL will *not* be visible
  56
+during testing.
  57
+
  58
+This change only affects the testing process. You can still use custom
  59
+SQL to load data into your production database as part of the syncdb
  60
+process. If you require data to exist during test conditions, you
  61
+should either insert it using :ref:`test fixtures
  62
+<topics-testing-fixtures>`, or using the ``setUp()`` method of your
  63
+test case.
1  docs/releases/index.txt
@@ -26,6 +26,7 @@ Final releases
26 26
 .. toctree::
27 27
    :maxdepth: 1
28 28
 
  29
+   1.2.5
29 30
    1.2.4
30 31
    1.2.2
31 32
    1.2

0 notes on commit 8151c04

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