Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

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

Anna | 16.06.2014 | нет комментариев
Приветствую, програлюди. Вчера в блоге знаменитого веб-фреймворка для питона, 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 сейчас поддерживает hourminute и second в дополнение к добавленным ранее yearmonth и day при поиске по полям с датой и/или временем.

Ну и обычный опрос. Волнует процентное соотношение, следственно если применяется несколько версий — имеет толк указать ту, на которой ведется основная разработка.

Какая у вас версия Django на продакшене?

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

Проголосовало 65 человек. Воздержалось 60 человек.

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB