From 00e7a571c5737c69bc225ae39d3dca6d0fbfd072 Mon Sep 17 00:00:00 2001 From: Carl Meyer Date: Wed, 26 Jan 2011 07:46:19 +0000 Subject: Fixed #6456 - Excised FileField file deletion to avoid data loss. Thanks to durdinator for the report. git-svn-id: http://code.djangoproject.com/svn/django/trunk@15321 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/releases/1.3.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'docs') diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 89e8b58585..1ca89380f7 100644 --- a/docs/releases/1.3.txt +++ b/docs/releases/1.3.txt @@ -261,6 +261,20 @@ requests. These include: Backwards-incompatible changes in 1.3 ===================================== +FileField no longer deletes 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). + PasswordInput default rendering behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.3