Pull to refresh

Встречайте, релиз Django 1.6

Website developmentPythonDjango
Django

Приветствую, хабралюди. Вчера в блоге популярного веб-фреймворка для питона, 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 при поиске по полям с датой и/или временем.

Ну и традиционный опрос. Интересует процентное соотношение, поэтому если используется несколько версий — имеет смысл указать ту, на которой ведется основная разработка.
Only registered users can participate in poll. Log in, please.
Какая у вас версия Django на продакшене?
13.58% >= 1.6 80
55.86% 1.5 329
23.43% 1.4 138
4.75% 1.3 28
0.51% 1.2 3
1.87% <= 1.1 11
Nobody voted yet. Nobody abstained.
Tags:djangopythonpython3releaseweb-разработкановости
Hubs: Website development Python Django
Total votes 58: ↑51 and ↓7+44
Views19K

Popular right now

Top of the last 24 hours