Как многие, без сомнения, знают, недавно вышла Django 1.1 beta. Там в release notes все самое вкусное перечислено, а я немножко вокруг покомментирую.
Одна из когда-то давно слезно просимых фич — загрузка объектов с неполным списком полей (aka "defer/only"). Раньше это делалось через .values()
, но результатом запроса был тупой набор значений. Новая фича возвращает полноценные объекты с недозаполненными полями. Поля заполняются отдельными запросами при первом обращении.
Теперь, по меткому выражению Малколма все кинутся этим пользоваться, потому что оно кажется очень крутым. Грустная ирония состоит в том, что если вы думаете, что вам нужны defer/only, это с высокой вероятностью либо преждевременная оптимизация, либо указание на неудачную модель базы. То есть, либо вы Реально Большие BLOB'ы храните в базе, вместо файлов, либо у вас в модели куча полей, которые можно и нужно разнести по разным моделям, провязанным один-к-одному. Впрочем, ладно, разберемся :-)
Еще одна фичка, про которую я даже не знал, пока в релиз нотах не прочитал — массовые действия над объектами в админке. Тоже давно просили все, чтобы массово что-нибудь удалять или проставлять флажки всякие. Что меня реально порадовало — это то, что фича сразу вышла хорошо проработанной в деталях:
- можно выдать юзеру свое сообщение типа "удалено столько-то объектов"
- можно вместо возвращения управления в админку передать объекты в свою вьюху, если над ними нужны какие-то многоходовые издевательства
- действие можно повесить как на одну модель, так и глобально для всех
А, да... Включенный сейчас по умолчанию "удалить все объекты" обещали сделать отключаемым. Не всем это надо :-)
Также совршенно нежданно-негаданно Малколм нашел время добить и скоммитить мой декоратор condition, который я когда-то писал для Cicero. Малколм его обобщил до работы не только с GET'ом, но и с остальными методами (PUT, POST, DELETE), которые могут обрабатывать ETag'и. Теперь Джанго реагирует на нужные заголовки с правильными HTTP-кодами. Ура! Писать REST-сервисы на Джанго теперь еще приятнее!
Ну и на закуску немножко приятных багфиксов:
7295: в шаблонных тегах теперь можно использовать кавычки любого типа
5756 и 6296: в параметрах шаблонных тегов теперь можно использовать фильтры (всеми любимый
{% ifequal list|length 5 %}
теперь должен работать)2698: наконец обработаны все краевые случаи с обращением к родительским объектам при использовании фильтрующих менеджеров по умолчанию (читай: теперь это можно делать без опасения наступить на туманные грабли)
8164: в ModelForms теперь можно удобно задавать порядок и полей модели и дополнительных полей формы
10194: появилась умная функция
django.shortcuts.redirect()
, которая принимает всякие значения и делать The Right Thing™. Например вместо:from django.core.urlresolvers import reverse from django.http import HttpResponseRedirect ... return HttpResponseRedirect(reverse(viewname, args=[param]))
теперь достаточно:
from django.shortcuts import redirect ... return redirect(viewname, param)
А у вас есть любимые фички в этом релизе?
Комментарии: 12
"defer/only" - без вопросов, любые кавычки в темплейтах давно ждал, впрочем, как и пакетные операции на обьектами в админке.
transactional fixtures, однозначно. В нашем последнем проекте есть тесты на производительность и обработку статистики, которые не сделать без большого объема тестовых данных. В 1.1 запуск всех тестов станет быстрее почти на порядок.
А по-моему одно из самых, на мой взгляд, важных нововведений в Django 1.1 - это, помимо Deferred field, ещё и так называемые Proxy Models. Они позволяют для одной модели данных определять несколько типов поведения.
Хотя, я за то, чтобы они сделали наконец нормальное наследование моделек (не только joined-table inheritance, но и остальные две стратегии - single table и concrete table inheritance), а не прикручивали непонятно что туда :)
list_editable в админке. Очень удобно для BooleanField.
Вот кстати, кто-нибудь может внятно объяснить, какой прок от этих defer() и only()?
bsdemon, if by "concrete table inheritance" you mean what Martin Fowler calls "concrete table inheritance" in his Enterprise Patterns book, Django already has that (Meta.abstract=True).
Single table inheritance is a really bad design pattern from the database point of view (you can't enforce data integrity in a lot of cases and it leads to wide tables, which perform poorly), so it's not going to be supported explicitly. Django encourages "best practices", not "every practice under the sun".
return redirect(viewname, args=[...])
с args не работает, только с позиционными параметрами, а жаль, было бы удобно просто перенести от HttpResponseRedirect...
На самом деле, я невнимательно прочитал. Все даже проще. Вот это:
эквивалентно просто:
То есть, он поддерживает явно и позиционные, и именованные параметры.
А вообще, именованные параметры в urlconf'ах довольно редко имеют смысл. Позиционных обычно хватает.
About concrete table inheritance - my bad, django can do it.
Malcolm, consider the following example - we have data model of group of people. Groups can be moderated, private, public and by that
type
we must distinguish group's behavior. It is the case for single table inheritance - we store all groups in single table and distinguish them bytype
field in that table. So we can have different python's classes for different group'stype
and so - different behavior for them.Django's brand new proxy models is a silly implementation of single-table inheritance design patterns (without polymorphic parameter
type
as sqlalchemy has, so ORM layer cannot decid).redirect действительно очень полезный шорткат, да и condition - отличная вкусность
Conditional view processing
Выдавать ETag и Last-Modified для динамики. Классная фича!!!