![Django](https://habrastorage.org/getpro/habr/post_images/255/08a/bc5/25508abc50b2c02243f7a68322a5490e.png)
Приветствую, хабралюди. Вчера в блоге популярного веб-фреймворка для питона, 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
при поиске по полям с датой и/или временем.Ну и традиционный опрос. Интересует процентное соотношение, поэтому если используется несколько версий — имеет смысл указать ту, на которой ведется основная разработка.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Какая у вас версия Django на продакшене?
13.58% >= 1.680
55.86% 1.5329
23.43% 1.4138
4.75% 1.328
0.51% 1.23
1.87% <= 1.111
Проголосовали 589 пользователей. Воздержались 478 пользователей.