Ответ 1
Querysets являются ленивыми, что означает, что они не вызывают базу данных до тех пор, пока они не будут оценены. Один из способов, которым они могли бы оцениваться, - это сериализовать их, что делает cache.set за кулисами. Таким образом, нет, это не пустая трата времени: все содержимое вашей модели Турнира будет кэшироваться, если это то, что вы хотите. Вероятно, это не так: и если вы затем отфильтруете запрос, Django просто вернется в базу данных, что сделало бы все это бессмысленным. Вы должны просто кэшировать экземпляры модели, которые вам действительно нужны.
Обратите внимание, что третья точка в вашем исходном наборе не совсем правильная, поскольку это не имеет никакого отношения к Apache или предпрохождению. Это просто, что представление является функцией, подобной любой другой, и все, что определено в локальной переменной внутри функции, выходит за пределы области действия, когда эта функция возвращается. Таким образом, набор запросов, определенный и оцениваемый внутри представления, выходит из области видимости, когда представление возвращает ответ, а новый будет создан при следующем вызове вида, то есть в следующем запросе. Это тот случай, который вы используете Django.
Однако, и это важно, если вы сделаете что-то вроде того, что задаете свой запрос на глобальную (модульную) переменную, он будет сохраняться между запросами. Большинство способов, которыми Django обслуживается, и это, безусловно, включает mod_wsgi, сохранить процесс для многих запросов до его утилизации, поэтому значение запроса будет одинаковым для всех этих запросов. Это может быть полезно в качестве своего рода кэша для транзакций, но трудно получить правильное решение, потому что вы не представляете, как долго длится процесс, а другие процессы, вероятно, будут выполняться параллельно, у которых есть свои собственные версии этой глобальной переменной.
Обновлено для ответа на вопросы в комментарии
Ваши вопросы показывают, что вы по-прежнему не очень разбираетесь в том, как работают запросы. Все о том, когда они оцениваются: если вы перечислите или переиментируете или нарезаете набор запросов, который его оценивает, и в этот момент выполняется вызов базы данных (здесь я рассчитываю сериализацию при итерации) и результаты, хранящиеся в внутренний кэш запросов. Итак, если вы уже сделали одну из этих вещей в своем наборе запросов, а затем установите его в (внешний) кеш, это не приведет к другому удару базы данных.
Но всякая операция filter() в наборе запросов, даже одна, которая уже была оценена, является другим ударом базы данных. Это потому, что это модификация базового SQL-запроса, поэтому Django возвращается к базе данных - и возвращает новый запрос с собственным внутренним кешем.