Есть ли способ сделать выбор быстрее, сделав его доступным только для чтения в ORM в django?

Question

Если я просто получаю список пользователей и не собираюсь обновлять этот список, могу ли я как-то пометить запрос как «только для чтения»?

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

Answer 1

Если я просто получаю список пользователей и не собираюсь обновлять этот список, могу ли я как-то пометить запрос как «только для чтения»?

AFAIK нет пути к этому. Я хотел бы знать, если кто-то думает / знает иначе.

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

Могу я спросить причину этого требования? Мне кажется, это преждевременная оптимизация. Если вы выполните какое-либо профилирование и и обнаружите, что производительность конкретного запроса низкая и считают, что его можно улучшить только , сделав набор запросов только для чтения, тогда этот вопрос вступает в игру. Вряд ли, ИМХО.

Answer 2

Вы можете просто удерживать набор запросов, и пока он оценивается, ему не нужно повторять запрос. Вы даже можете прикрепить это к запросу.

Пример:

# in the view, a decorator, or middleware
request._my_users = Users.objects.all()
request._my_users[:]

# Later reference request._my_users

Answer 3

ORM не нужно отслеживать выбранные строки, вместо этого он идентифицирует строки по их первичному ключу, чтобы определить, вставлять или обновлять (если вы не установили force_insert или force_update с помощью save ()).

Кто может прочитать об этом здесь: http://docs.djangoproject.com/en/1.2/ref/models/instances/#how-django-knows-to-update-vs-insert

При этом нет необходимости или даже возможности использовать модель «только для чтения», поскольку она не приведет к улучшению производительности.

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

Например, позвоните querySet.exists() resp,querySet.count() вместо (bool)querySet соотв.len(querySet) если (и только если) вы не читаете из запроса, заданного впоследствии.В противном случае не используйте exist () / count (), так как он создаст дополнительный запрос, тогда как в последнем кеше фактическое чтение набора запросов бесплатное, поскольку оно уже кешируется.

Другая мера - использовать only () и defer (), чтобы ограничить SELECT полями, которые вам действительно нужны, и select_related () для предварительной выборки отношений внешнего ключа, если вы знаете, что они вам понадобятся.Если у вас есть большие модели с большим количеством связей и столбцов, это может значительно повысить производительность.