[1.3.X] Fixes #15588 -- 1.3 release documentation for FileField no longer deleting files unclear. Thanks for the patch, Philip Neustrom.

Backport of r16205 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.3.X@16206 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Chris Beaven 2011-05-10 00:20:21 +00:00
parent fda65ffea5
commit 4cb2b53c22
1 changed files with 8 additions and 7 deletions

View File

@ -358,19 +358,20 @@ issues`_ reported to us, however, query string lookup arguments in the
admin must be for fields or relations specified in ``list_filter`` or
``date_hierarchy``.
FileField no longer deletes files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deleting a model doesn't delete associated files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In earlier Django versions, when a model instance containing a
:class:`~django.db.models.FileField` was deleted,
:class:`~django.db.models.FileField` took it upon itself to also delete the
file from the backend storage. This opened the door to several data-loss
scenarios, including rolled-back transactions and fields on different models
referencing the same file. In Django 1.3, :class:`~django.db.models.FileField`
will never delete files from the backend storage. If you need cleanup of
orphaned files, you'll need to handle it yourself (for instance, with a custom
management command that can be run manually or scheduled to run periodically
via e.g. cron).
referencing the same file. In Django 1.3, when a model is deleted the
:class:`~django.db.models.FileField`'s
:func:`~django.db.models.FileField.delete` method won't be called. If you
need cleanup of orphaned files, you'll need to handle it yourself (for
instance, with a custom management command that can be run manually or
scheduled to run periodically via e.g. cron).
PasswordInput default rendering behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~