Конвертеры маршрутов в Django 2.0+ (path converters)

Ого, честно, не подумал бы даже делать такое на конвертерах :)
Если приходится для роутинга лезть в БД, то тут как ни крути — придется лезть в БД. Кажется, что в обработчике будет меньше запросов (если сам объект знает все что нужно, чтобы выбрать нужный роут).

Конвертеры маршрутов в Django 2.0+ (path converters)

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

А размывание логики не стоит допускать — задача конвертера только дать ответ: могу сконвертировать или нет = маршрут не подходит, сайд эффекты привносить в конвертер точно не стоит :)

Я к конвертерам скорее отношусь как к сериализаторам из DRF, только которые принудительно вызываются до обработчика, а не внутри.

Конвертеры маршрутов в Django 2.0+ (path converters)

Спасибо за комментарий!

.all() кеширует результаты при исполнении, а как раз в приведенном конвертере исполняется не .all(), а .get(), поэтому проблем не возникнет.

При этом получаем возможность в декларативном стиле добавлять фильтрации:

queryset = User.objects.filter(is_active=True)

Если же захочется в конвертере использовать .all(), то тогда в нем же и стоит позаботиться об актуальности данных :)

def to_python(self, value: str):
    # ensure queryset is re-evaluated
    queryset = self.queryset.all()
    # process queryset

Но пока не могу представить себе конвертер, в котором это потребовалось бы.

Про видовые классы и re_path не понял. Финальная view-функция выглядит так:

path('users/<user:u>/reports/<date:dt>/', user_report, name='user_report')

def user_report(request, u: User, dt: datetime):  
    # logic

CBV выглядел бы так:

path('users/<user:u>/reports/<date:dt>/', UserReport.as_view(), name='user_report')

class UserReport(generic.View):
    def get(self, request, u: User, dt: datetime): 
        # logic

Можно пояснение, что имелось ввиду?

Что же касается логики получения самого отчета — действительно, возможно нужны будут связанные модели и сам User не нужен вовсе, а возможно улетит запрос в сторонний сервис и нужен будет некий токен из модели User. Тут уже зависит от задач — если обработчик использует user_id — значит его и получаем, если же использует User, то хотелось бы получить User на вход.

А вот насчет отсутствия request согласен. Сделать запрос в БД, чтобы убедиться в валидности маршрута, а потом узнать что нет прав на исполнение этого обработчика и можно было бы не делать запрос в БД — грустный сценарий. Это будет бить по производительности.

При этом разрешать вопрос прав нужно не в конвертере или URLResolver, это не их забота, а частично до (вот этого слоя не хватает, простые проверки, типа маршрут только для админа) и частично после (в обработчике).

На практике же, действительно, пока из самописных конвертеров я использую только конвертер для даты :)

Конвертеры маршрутов в Django 2.0+ (path converters)

Точно, спасибо!
Исправил ;)