Комментарии 29
Сказать??
Ура товарищи :-) Неделя django на хабре началась.
В документации не отмечено изменение, важное для России: Доменная зона РФ теперь проходит валидацию урлов.
Наконец-то!
А подскажите — если я на транке сейчас, то сделав апдейт я 1.3 финальный релиз получу?
А подскажите — если я на транке сейчас, то сделав апдейт я 1.3 финальный релиз получу?
Как известно хорошим программный продукт становится не раньше чем с третьей версии, поэтому ждем скорого релиза 3.1 :)
Нововведения это хорошо, но мне большие интересно когда они закроют старые баги, такие как утечка дискового пространства при перезаливке файла в FileField.
Это ж не баг, а описанное в документации поведение, и сделано это сознательно. При необходимости легко перекрывается. Кстати, из лога изменений в 1.3 :)
FileField no longer deletes files
In earlier Django versions, when a model instance containing a FileField was deleted, 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, 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).
Какая жесть (
И какое решение? Наследоваться от FileField/ImageField и в нем перекрывать поведение?
И какое решение? Наследоваться от FileField/ImageField и в нем перекрывать поведение?
В FileField хранится не файл, а путь к файлу. Откуда этот путь берется — при загрузке формы пользователем или нет — джанге неизвестно. На один файл может ссылаться произвольное количество FileField (самый банальный пример — значение по умолчанию).
Ну, например, с ImageField — назначать мальчикам мальчиковую аватарку, если своей нет, а девочкам — девочковую можно.
Или несколько проектов на одном сервере могут через FileField ссылаться на одни и те же файлы, которые лежат в каком-то общем месте.
Поэтому поведение «удалять по умолчанию» будет в общем случае приводить к потере данных, от чего джанга защищает.
Если хотите изменить поведение глобально — укажите в DEFAULT_FILE_STORAGE свой класс (наследника FileSystemStorage), который будет заменять файлы при сохранении, а не добавлять к названию _1 _2 и т.д.
Что-то вроде этого (из головы пишу, не проверял):
Если не глобально — у полей есть опция storage.
Ну, например, с ImageField — назначать мальчикам мальчиковую аватарку, если своей нет, а девочкам — девочковую можно.
Или несколько проектов на одном сервере могут через FileField ссылаться на одни и те же файлы, которые лежат в каком-то общем месте.
Поэтому поведение «удалять по умолчанию» будет в общем случае приводить к потере данных, от чего джанга защищает.
Если хотите изменить поведение глобально — укажите в DEFAULT_FILE_STORAGE свой класс (наследника FileSystemStorage), который будет заменять файлы при сохранении, а не добавлять к названию _1 _2 и т.д.
Что-то вроде этого (из головы пишу, не проверял):
# my_storages.py
from django.core.files.storage import FileSystemStorage
class ReplacingFileStorage(FileSystemStorage):
def _save(self, name, content):
self.delete(name)
return super(ReplacingFileStorage, self)._save(name, content)
# settings.py
DEFAULT_FILE_STORAGE = 'my_storages.ReplacingFileStorage'
Если не глобально — у полей есть опция storage.
Спасибо огромное за подробное объяснение.
Готовые примеры FileStorages можно посмотреть в модуле storages.
Сспасиб за новость. С утра проверял — была 1.2.5, а тут ништячек приятный под вечер.
«Скачать» is unpythonic, pip install Django -U.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Релиз Django 1.3