set_many(), delete_many() и clear() у кэша

Думаю по именам понятно кто-что делает.
set_many - принимает дикт
delete_many - хочет что-то итерирумое c ключами
clear - ничего не хочет, просто очищает кэш.

Что забавно в сообщении к коммиту написанно про get_many, но в диффе delete_many.
И что еще забавнее, говнокодеры опять используют dict.items для итерации, а не dict.iteritems (

jQuery в админке

Сделали скрытие формы под новый элемент у инлайнов, и добавили jQuery.
Тем кто использовал сабж, провериться на конфликты!

Права анонимуса

Теперь анонимусы не бесправны!

После дискуссии в django-developers, расширили возможности авторизационных бэкендов.
Для новой фици, объявите supports_anonymous_user = True в своем бэкенде.
После этого в метод get_all_permissions начнут попадать анонимусы.

Теперь и на Албанском

сабж в джанге

Объектные вьюшки фидов

К релизу 1.2 в джанге поменяли систему вывода rss/atom лент.

Раньше схема была: описываешь класс, наследник от django.contrib.syndication.feeds.Feed и указываешь на него вьюшке django.contrib.syndication.views.feed.
Которая в свою очередь описывалась в урлах примерно так

Удобные фиксчи

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

{
    "pk": 1,
    "model": "store.book",
    "fields": {
        "name": "Mostly Harmless",
        "author": 42
    }
}

Думаю, знакомая штука )
Вроде бы все отлично, данные мы сохранили.
Но бывает их надо править руками, и тогда начинается настоящий гемор с поиском, т.к. "author": 42 - это совсем не говорящее указание.

Ведь, куда приятнее искать автора не по безликому pk, а по имени.
Кстати, так и сделали )

Read-only поля в админке

Релиз 1.2 меня прям радует своей человечностью )
Хотели read-only поля в админке? Получите, распишитесь.

К admin.ModelAdmin добавился новый атрибут: readonly_fields.
В использовании схож с list_display, т.е. можно указать не только поля модели, но и методы объекта админки.

И надо учесть что, если вы не задали порядок в fields или fieldsets, то read-only поля будут идти после обычных.

Человечный SQL

Джанга всегда славилась удобством из коробки, но как только тебе надо чуть больше, чем положено, начинается гемор...
Хороший пример это sql запрос, который стандартный ORM не позволял составить.
Правда, не буду лукавить, есть 2 метода запихивания своего sql в запрос:

1. Обращение к базе минуя ORM
   

   connect.cursor().execute('SELECT * FROM `person`;')

   Большим минусом является, то что на выходе у нас список списков, а не объектов нужной нам модели.
   
2. Дополнение запроса от ORM
   

   Books.objects.filter(pages__gte=123).extra(select={'result': 'SUM(cost)'})

   Тут минус - в ограниченности.
   

Правда, сейчас extra почти не нужен, его земенил annotate.
Но вселенского счастья все равно не наступило )

И тут, ВНЕЗАПНО... ревизия 11921 и Model.objects.raw офигеть! )

Прощай ifequal

Думаю, всех задолбали кострированные темплейты в джанге, но в силу привычки/наличия существующего кода или еще чего люди с них не уходят и продолжают жрать кактус )

Самая простая ситуация:

if len(words) > 10:   print wordselse:   print trim(words)

Решается в джанге ну очень не явным способом )
Писался фильтр типа такого:

def gt(value, count):    return value > count

И использовался, как

{% if word|length|gt:3 %}

Думаю, вы согласитесь это выглядит упячисто (

Конечно, можно было использовать уже готовые решения из снипитов. Но если это надо только на одной странице, то мне очень сильно лень искать и подключать сторонюю библиотеку. Вот если бы все уже было в транке...

Новая система сообщений

Надавно закрылся еще один двух годичный тикет, "session-based messages". И уже давно пора, а то успел понаплодиться зоопарк решений:
http://code.google.com/p/django-notify/
http://djangoflash.destaquenet.com/
http://code.google.com/p/django-session-messages/

Дело в том, что изначально в джанге сообщения можно было создавать только для авторизованных пользователей, чего явно не достаточно. Самое просто решение было складывать мессаги в сессию:

request.session['messages'] = ('Hi user', )

А потом выдергивать в темплейте, думаю, так было сделано не мало велосипедов )

Итак, сейчас у нас есть django.contrib.messages и что приятно они не поломали обратную совместимость )

Template cache

Есть у меня дурная привычка, просматривать svn log джанги по утрам, благодаря которой и появился этот блог, в общем, встречайте первый блин:

Сегодня я хочу поговорить о тормозах, и, как мне кажется, самое медленное место в джанге (помимо кривых рук программистов) это темплейты.

Сам принцип их работы очень напоминает cgi - на каждый запрос мы все делаем заново, заново ищем файл, заново читаем файл (или еще что) и наконец заново компилируем (получаем объект Template).
Конечно на этом работа с темплейтами не заканчивается, сам рендеринг еще не начинался, и основные тормоза как раз в нем, но повторюсь это выполняется на каждый запрос, и это правда не быстро.

Для решения этой проблемы 2 года назад открыли тикет 6262, предлагалось кэшировать темплейты после их первой загрузки, все бы хорошо, и сама задача выглядит не сложной, но есть забавные подводные камни.