Пустой image.url в кэше

Кладу её в кэш

Тут поподробнее...

cache.set(key, model)

Ничего необычного не делаю.

Про кеш ничего не известно. Условие задачи можно значительно расширить.

https://bitbucket.org/neko259/neboard/src/30262d21650058e5df707c43a4ec22568ed...

Строка 415, закомменченый кусок.

Пользуясь случаем

auto_now & auto_now_add

в all().order_by() или all().exists() all не нужен

if self.replies.count() > 0: -> if self.replies.exists():

if len(title) == 0: -> if not title:

а так — неплохо, читается.

auto_now ты на pub_time предлагаешь повесить?

Хочется кэшировать модели — есть смысл посмотреть на johnny-cache. В идеале в кэше должны храниться не данные, а уже «ответы» на «вопросы». Т.е. отрендеренные куски html/json, а не сырые модели (тем более прямо из orm).

У меня там вот какая проблема. У поста часто проверяется, первый он в треде (ОП) или нет. У многих постов. Проверяется сравнением первого поста и текущего. Вот я и хотел закэшировать первый пост. Его рендерить не надо, только сравнить.

Как вариант. Или default=timezone.now.

Угу. Эта часть писалась ещё в зайчатках, когда я плохо знал джангу. Сейчас вот рефакторю понемногу.

Сильно не смотрел, но если это в пределах одного запроса, то можно не париться с кэшем, хранить в инстансе как self._opening_post.

В каком смысле хранить в инстансе? Как поле модели или просто как переменную? Если второе, то оно же не будет шариться между юзерами.

Пока сделал кэш на opening_post_id, там проблем вроде нет.

Раз уж ты здесь. Подскажи ссылки на открытые джанго-проекты с хорошим кодом. Хочу посмотреть на best practices.

У поста часто проверяется, первый он в треде (ОП) или нет.

Зачем?

У меня общий шаблон поста на ОП (с тегами и кнопочкой «ответ»), архив и просто пост. Потому что у них много одинаковых элементов. И внутри этого шаблона мы проверяем, какие из этих особенностей показывать. Так вот каждый пост рендерится отдельно и не знает, ОП он или нет. Пока сделано немного костыльно, сверху в него передаётся инфа из треда. Иначе каждый пост будет дёргать базу и тормозить.

Так и не увидел у тебя настройки кеша. LocMemCache используешь в продакшене что ли?

Memcached.

Да любой зрелый открывай да смотри. Другое дело, что иногда джанга сама подталкивает или вынуждает писать non-pythonic код. Поэтому лучше не ограничивать себя фреймворком.

Если под джангу, то есть sorl-thumbnail, для генерации понятно чего. Есть работа с полями моделей, с админкой... Первое, что пришло в голову.

Best practices есть http://lincolnloop.com/django-best-practices/ например. Но там не много.

В любом случае, если ты дошёл до class-based views, то это уже хорошо, потому что даже в django.contrib народ не парится и делает всё по-старинке на функциях. Используй cbv, используй разные generic cbv (TemplateView, например). Если каждый раз для нового view пытаться использовать что-то из готового (CreateView, UpdateView), то будешь чётче понимать, что ты делаешь.

https://docs.djangoproject.com/en/1.4/ref/class-based-views/ (в 1.4 дока одним куском, потом разбили)

Если взять AuthorsView из views/authors.py, то какой класс он должен расширять? Он всего лишь берёт данные не из базы и рисует страничку, используя неизменный шаблон. Если сделать его TemplateView, можно просто сделать у него атрибут template_name и расширить get_context_data, чтобы включить authors. PostAdminView — это похоже UpdateView. Профит от переделки в generic cbv — не нужно будет писать везде self.get_context_data(request=request), можно будет закрыть view для не-админов декоратором (нет копипасте). Плюс self._get_user можно вынести в middleware, а BaseBoardView._default_context превратить в context processor.

Такие тонкости нужно скорее искать в доках или даже на stack overflow. Хотя это можно подсмотреть в коде открытых «сайтов», написанных на джанге. Тут я не могу подсказать, я только django-cms знаю.

Странно как-то, хотя может я не вижу всей картины.

Что именно странно?