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

    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 при поиске по полям с датой и/или временем.

    Ну и традиционный опрос. Интересует процентное соотношение, поэтому если используется несколько версий — имеет смысл указать ту, на которой ведется основная разработка.
    Какая у вас версия Django на продакшене?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Метки:
    Поделиться публикацией
    Комментарии 15
    • +9
      Даешь миграцию DB!!! Ждем
      • +3
        Она будет доступна только в 1.7
        • +3
          Все равно ждём.
          • +2
            Если верить kickstarter то будут backports для 1.5 и 1.4
            A backport of the key features to a new major version of South to support those on Django 1.4 and 1.5
            • +2
              Вообще, да, но это в виде бэкпорта для South. К слову сказать, ветку с миграциями смерджили не так давно — в конце августа этого года, поэтому вполне возможно, что бэкпорты либо уже есть, либо в процессе (я не отслеживаю эту сторону миграций, если честно).
            • 0
              Вы уверены? Можно ссылку на источник с этой инфой?
                • 0
                  Тот pr ещё тут светился, а andrew godwin говорил, что все сделает к июлю 2013. Но то, что официальная дока пишет про 1.7 не может не радовать.
                  • 0
                    Все так, но на момент написания той статьи, PR был всего-лишь черновиком, а в настоящий момент он уже смержен в мастер, т.е. по сути, в дев-ветку. И если каких-нибудь критичных казусов не выявится, то фича попадет в следующий релиз.
          • +3
            А что там с python 3? Пристально не слежу, но вроде как 1.6 должна была стать версией с полной поддержкой 3й версии или как-то так?
            • +2
              Так и есть, python 3 теперь официально поддерживается, но особое внимание на этом не заостряется. Т.е. видимо, проблем с совместимостью уже нет, но к каким-то более кардинальным действиям, типа вести разработку на тройке, а потом добиваться совместимости с двойкой (сейчас как раз наоборот) — вроде бы нет.
              На последнем djangodash, кстати, было интересно, что достаточно много проектов писались и запускались именно на 3й ветке питона.
              • +3
                Но я так понимаю остаются вопросы с совместимостью батареек?
                • +2
                  Конечно, особенно там, где разработчики подзабили.
                  С другой стороны, все что покрупнее или очень популярное — оно все уже поддерживает третью ветку (обычно 3.2+).

                  Есть еще, конечно, всякие исторически очень популярные решения, которыми сегодня никто особенно не занимается (MySQL-python, PIL), но их обычно тоже форкают и заменяют. Скажем, новая джанга предпочитает pillow, а PIL — останется для совместимости до 1.8.
                  • –1
                    Батарейки — это то что в дистрибутиве самого питона, никаких проблем с совместимостью у них и быть не может. А то, что вы имеете в виду — это не батарейки.
                    • –1
                      Минусующие забыли написать свою точку зрения на этот счет. Или забыли прочесть официальные буквы по этому поводу.
                      Ничего, я тут повторю для лентяев. Fans of Python use the phrase «batteries included» to describe the standard library.

                      И-и-и? У стандартной библиотеки появились какие-то проблемы с Python 3? Ваши PIL и MySQL-Python — это не batteries, се ля ви. Чем размахивать минусометами, лучше бы использовали правильную терминологию — для программистов не самое бесполезное умение.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.