Хочу рассказать о нескольких неприятных моментах (читай "ошибках"), с которыми совсем недавно столкнулся при использовании
django-lfs:
Ошибки при сохранении картинок с длинными именами
Для хранения картинок в django-lfs используется специальный тип поля, пронаследованный от стандартного ImageFile. В этом стандартном типе дефолтная длина файла картинки 100 символов.
В модели , которая используется для хранения картинок товаров , например, max_length явно не указывается. В итоге при попытке отобразить превьюхи (thumbs) оригинальной картинки с длинным именем ( >= 100 символов), случается поначалу непонятный IndexOutOfRange..Казалось бы причем тут массивы...
Вот такой замечательный код есть..
class ImageWithThumbsFieldFile(ImageFieldFile):
"""
See ImageWithThumbsField for usage example
"""
def __init__(self, *args, **kwargs):
super(ImageWithThumbsFieldFile, self).__init__(*args, **kwargs)
self.sizes = self.field.sizes
if self.sizes:
def get_size(self, size):
if not self:
return ''
else:
split = self.url.rsplit('.', 1)
thumb_url = '%s.%sx%s.%s' % (split[0], w, h, split[1])
return thumb_url
падает, как нетрудно догадаться, в строчке
thumb_url = '%s.%sx%s.%s' % (split[0], w, h, split[1])
Причина в том, чтo в rsplit передается усеченное имя файла.. Как видим, никакими дополнительными проверками авторы себя не обременили, поэтому дело и доходит до "пятисоток"..
Запретить пользователям не аплоадить такие картинки - нельзя.
Планирую следующий фикс: все картинки, поступающие в django-lfs сохранять под сгенерированными уникальными именами заранее фиксированной длины.
А пока для своих проектов на django-lfs сделал небольшой костыль в виде max_length = 2048 в описании модели картинки.
Глюки с редактированием товаров в manage-интерфейсе
django-lfs позиционируется как шустрый фреймворк для ешопов. Шустрость его в частности основана на активном использовании кеширования бд.
Баг , который я сейчас опишу, как раз и проявляется при использовании кеширования.
Допустим , вы используете кеширование в таблице БД. Выставляете время жизни объектов в кеше , например , в 60 секунд.
Пользователь магазина наконец-то решает заняться наполнением. Создает товар, редактирует "данные" и сохраняет их . Затем переходит на "категории" и вносит товар в нужные категории. "Сохранить категории". Лезет на сайт, а товара там нет... Лезет в интерфейс управления и видит, что "активно" , не выставлен, цены нет и вообще вкладка "данные" такая, как будто он к ней не прикасался.
Причина в том, что между сохранением "данных" и сохранением "категорий" не прошло минуты и при сохранении категорий, товар взялся из кеша.
Вопрос, почему не был обновлен кеш при сохранении "данных" , пока открыт. Выясню и исправлю, ведь без кеширования как-то несолидно :)
Да и есть такие django-модули, которые без
кеширования вообще не работают. Например, используемый многими
supercaptcha.
UPD:
Глюк с редактированием товаров исправляется отправкой сигнала product_changed в products.py (после сохранения формы данных), а также с отправкой аналогичного сигнала при изменении категорий товара.
