Как оптимизировать пагинаторный модуль Django - PullRequest
1 голос
/ 05 января 2011

У меня есть вопрос о том, как работает модуль пагинатора Django и как его оптимизировать.У меня есть список из примерно 300 элементов информации, которую я получаю из различных API в Интернете.Я использую модуль django paginator для отображения списка моих посетителей, по 10 штук за раз.Нумерация страниц не работает так, как я хочу.Кажется, что пагинатор должен получить все 300 элементов, прежде чем вытащить десять, которые должны отображаться при каждом изменении страницы.Например, если имеется 30 страниц, то для перехода на страницу 2 требуется, чтобы мой веб-сайт снова запросил API, поместил всю информацию в список и затем получил доступ к десяти запросам, которые запрашивает браузер посетителя.Я не хочу продолжать запрашивать у API ту же информацию, которая у меня уже есть на каждом повороте страницы.

В настоящее время в моих представлениях есть функция, которая просматривает запрос get и запрашивает у API информацию, основанную назапрос.Затем он помещает всю эту информацию в список и передает ее в файл шаблона.Итак, эта функция всегда загружается всякий раз, когда кто-то переворачивает страницу, что приводит к повторному запросу API.

Как мне это исправить?

Спасибо за вашу помощь.

Ответы [ 2 ]

1 голос
/ 05 января 2011

В этом случае paginator потребуется полный список, чтобы выполнить свою работу.

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

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

0 голосов
/ 05 января 2011

ORM не загружают данные до тех пор, пока не будет выбрана строка:

query_results = Foo(id=1) # No sql executed yet, just stored.

foo = query_results[0] # now it fires

или

for foo in query_results:
   foo.bar() # sql fires

Если вы используете пользовательский источник данных, который загружает результаты при инициализации, тогда разбиение на страницы не будет работать должным образом, так как все каналы будут выбраны одновременно. Вы можете захотеть создать подкласс __getitem__ или __iter__ для фактической выборки. Затем он будет совпадать с тем, как Django ожидает загрузки результатов.

Для нумерации страниц нужно знать, сколько существует результатов для таких вещей, как has_next (). В sql это обычно недорого, чтобы получить count(*) с индексом. Таким образом, вы также хотели бы знать, сколько будет результатов (или, может быть, просто оценить, если точно знать, что это слишком дорого).

...