Django — это фреймворк для веб-приложений с открытым исходным кодом для Python. В выпуске Django 4.1 мы получили некоторые долгожданные улучшения, такие как асинхронные представления, асинхронные запросы к базе данных и устаревание, которое в конечном итоге предотвратит выход ваших пользователей из системы, если вы не измените свой код соответствующим образом.

Устаревший выход из системы через GET

Выход — это действие, оказывающее побочный эффект на хранилище приложения: регистрация out call request.session.flush. Как правило, небезопасные операции, которые имеют побочный эффект для зависимости, такой как база данных или кеш, должны выполняться не с помощью GET, а с помощью POST, PATCH, PUT, DELETE и т. д. Причина отказа от использования GET заключается в том, что побочный эффект может быть вызван. просто загрузив веб-страницу. Много места для злоупотреблений и неожиданного поведения:

  • Браузер может предварительно выбрать страницу для отображения на странице новой вкладки. Хотели бы вы, чтобы сбросить сеанс?
  • Тролль может гиперссылаться на страницу выхода, чтобы пользователи могли выйти из системы.

До версии 4.1 у Django не было мнения о выходе из системы через GET. Однако сейчас это устарело.

Практически это означает, что вы больше не связываете кнопку «выход» с видом выхода из системы (который будет запросом GET), а вместо этого делаете что-то вроде

<form>
  {% csrf_token %}
  <button formmethod="{% url 'admin:logout' %}" formmethod="post" type="submit">Logout</button>
</form>

Если formaction или formmethod для вас новы, смотрите документацию здесь.

Асинхронные представления на основе классов

Обработчик асинхронного представления позволяет запускать параллельную программу, в которой единица работы может выполняться без привязки к основному потоку приложения. Не только это, но также уведомляет вызывающий поток, если он терпит неудачу, завершается или прогрессирует.

Подклассы View могут определять обработчики асинхронных async defметодов, чтобы влиять на асинхронный код с помощью await:

import asyncio
from django.http import HttpResponse
from django.views import View

class AsyncView(View):
    async def get(self, request, *args, **kwargs):
        # Perform io-blocking view logic using await.sleep
        await asyncio.sleep(1)
        return HttpResponse("Hello async world!")

В классе представления необходимо, чтобы все пользовательские обработчики методов были либо полностью синхронными (с использованием def), либо полностью асинхронными (с использованиемasync def). Если это не так и async def declarations смешаны с def, при вызове as_view()isвозникнет исключение ImproperlyConfigured.

Django автоматически определяет async представлений и запускает их в асинхронном контексте.

Асинхронные запросы

До Django 4.1 при написании кода async запросы ORM были недоступны, поскольку запросы к базе данных блокировались: блокировка синхронного кода блокировала цикл обработки событий. Действительно, Джанго заметит это и поднимет SynchronousOnlyOperation, чтобы остановить его. Вот тут-то и появляются асинхронные запросы!

С асинхронными запросами вы можете выполнять столько запросов, сколько хотите, используя API асинхронных запросов Django. Каждый запрос, который может быть заблокирован, например delete или get, имеет асинхронный вариант, который называется adelete или aget. При повторении результатов можно просто использовать асинхронный повтор (async for). Например:

async for entry in Authors.objects.filter(name__startswith=”A”):
    ...

Улучшите свой код Django

Code Review Doctor — это инструмент сканирования кода, который предлагает исправления Python и Django прямо в вашем запросе на включение.

Проверьте свои пулл-реквесты GitHub или Bitbucket, сканируйте всю кодовую базу бесплатно онлайн или подпишитесь на нас в Twitter.