Приветствую, читатели. Вчера в блоге популярного веб-фреймворка для питона, Django, появилась новость о релизе новой версии под номером 1.6.
Полный перечень всех новшеств, а также информация об изменениях (в том числе и обратно несовместимых) традиционно находится в заметках к релизу. По моим ощущениям, на этот раз разработчики сфокусировались в большей степени на работе с БД.
В данной статье-новости я хотел бы отметить основные, на мой взгляд, изменения.
Работа с транзакциями
В 1.6 появилось новое API для работы с транзакциями. Начиная с этой версии привычные для работы с транзакциями функции autocommit(), commit_on_success() и commit_manually() из модуля django.db.transaction теперь считаются устаревшими и останутся для совместимости до 1.8. На их замену приходит atomic().
Основная логика здесь примерно следующая: ранее, ключевым моментом был механизм управления поведением при работе с коммитом транзакции — автокоммитом (т.е. каждый SQL-запрос начинает транзакцию и коммитит ее автоматом) или ручным коммитом (COMMIT; SQL-запрос отправляется самостоятельно). Этот механизм довольно хорошо работал в случае независимых транзакций, но вот в случае вложенного использования устаревших функций — результат мог быть некорректен. Например если у нас есть два вложенных один в другой блока commit_on_success(), то может возникнуть такая ситуация, что результат выполнения внутреннего блока будет закоммичен, поломав, с точки зрения транзакций, атомарность внешнего блока.
Что будет теперь: во-первых, джанга теперь по умолчанию включает режим автокоммита, стоит заметить, нарушая при этом PEP 249. А во-вторых, единственным механизмом работы с транзакциями становится atomic(), который не боится вложенности, т.к. в случае внешнего блока — работает с транзакцией, а в случае вложенного — с SQL'ными точками сохранения. Также теперь вместо TransactionMiddleware доступна конфигурационная константа ATOMIC_REQUESTS, при установке значения которой в True (дефолтное значение — False), джанго будет стараться обработать один HTTP запрос в одной транзакции. Т.е. выполнился запрос без каких-либо проблем — закоммитили, нет — откатили.
Надо заметить, что atomic() может использоваться как декоратор, так и как менеджер контекста:
from django.db import transaction
# декоратор
@transaction.atomic
def viewfunc1(request):
# этот код будет выполнен внутри транзакции
do_stuff()
and as a context manager:
# менеджер контекста
def viewfunc2(request):
# этот код выполняется в режиме автокоммита
do_stuff()
with transaction.atomic():
# а здесь уже выполняется внутри транзакции
do_more_stuff()
Более подробное описание — как всегда, доступно в документации.
Постоянные соединения с БД
Это, конечно, не пулл соединений, т.к. они изолированы потоками, в которых запущено приложение. Но, это уже гораздо лучше, с точки зрения производительности, чем постоянное подключение к базе при каждом HTTP запросе. Время жизни соединений регулируется конфигурационной константой CONN_MAX_AGE.
Тесты
В 1.6 появился новый запускальщик тестов django.test.runner.DiscoverRunner, который использует логику поиска модулей с тестами из unittest2. Теперь тесты могут располагаться в любых модулях, если имя файла, содержащего их соответствует маске test*.py.
Правда, при этом, тесты из models.py и tests/__init__.py найдены, и соответственно, запущены не будут (в отличие от поведения в предыдущих версиях). Самым простым решением является переименовывание их в что-либо вида test_models.py и tests/test.py. А также, доктесты больше не будут подгружаться автоматом. Но их будет не сложно включить обратно, следуя указаниям из документации по unittest.
Кстати, у management-команды ./manage.py test теперь появилась опция --pattern, указав которую, как не трудно догадаться, можно менять маску для поиска файлов с тестами.
Management-команда check
Команда django-admin.py check теперь позволяет проверить совместимость проекта или приложения с текущей версией джанги, выдавая оповещения в случае нахождения несовместимых мест. Предполагается, что эта команда будет помогать при переходе на новые версии фреймворка.
Кстати, 1.6 — это последний релиз джанги, в котором еще поддерживается питон версии 2.6. Со следующего релиза будет требоваться как минимум 2.7 питон.
Улучшения ORM
Теперь QuerySet поддерживает синтаксический сахар, в виде методов first() и last(), а тажке earliest() в дополнение к latest().
ORM теперь поддерживает hour, minute и second в дополнение к добавленным ранее year, month и day при поиске по полям с датой и/или временем.
Ну и традиционный опрос. Интересует процентное соотношение, поэтому если используется несколько версий — имеет смысл указать ту, на которой ведется основная разработка.
Автор: wronglink
