Комментарии 10
работает в частном случае сортировки только по ключу, причем "последнее" требует ксилий. как только добавится сортировка по произвольному полю — опять все сломается… и да, оно требует возрастания айди по мере вставки, много ли баз такое гарантируют? как и отсутствие дырок...
Сортировку можно подставить любую, главное условие — она должна работать как по возрастанию так и по убыванию, т.е основная идея в том, чтобы развернуть всё в обратную сторону и идти с конца а не с начала. В arangodb, которую я использовал, генерация id зависит от текущего времени, т.е есть разрывы [224, 368, ...].
в базе с транзакциями будет так:
1) начали транзакцию
2) вставили строку в таблицу и вернули айдишку, чтобы использовать в дочерней таблице
3) тут внезапно уснули на каком iowait
4) сделали еще что-то
5) заккомитили
вот тогда в пункте 3 другой процесс может быстренько вставить строчку уже с n+1 и ваше приложение выбрать это изменение, а потом внезапно пункт пять и n возникает...
А вариант с передачей на сервер последнего id с предыдущей страницы не рассматривали?
Если рассматривали, то чем это не устроило?
Рассматривал. В таком случае при добавлении нового id, все последние id в последующих запросах сместятся на 1, и прошлый кэш станет бесполезен. Можно возвращать динамическое количество элементов при первом запросе, чтобы этого избежать, но в таком случае это почти ничем не отличается от подхода из статьи, кроме использования фильтра по id вместо прямого смещения.
Безусловно, Ваш метод интересен для случаев, когда содержимое пагинации общее для всех (многих) пользователей и не подвергается персонализированной фильтрации и сортировке, однако сейчас такое встречается всё реже.
Если я вдруг пропустил какой-то очевидный случай пагинации с контентом, одинаковым для массы пользователей — расскажите про него, пожалуйста)
Не получится кешировать результаты, т.к посты находящиеся на странице 2, при добавлении новых, непременно сместятся на страницу 3, 4 и так далее, т.е одна и та же операция GET возвращает разные результаты в зависимости от количества постов.
Получится, я придумал давно , как это сделать.
Нужно использовать обратный страничник.
Это логично.
У меня на сайте, например, именно он и реализован. Для блогов, то есть, когда новая запись добавляется в начало.
Таким образом на 31 странице записи будут постоянно одни и те же, даже если добавят новые.
Бесконечный скроллинг это неудобно для того, чтобы после вернуться на то же место (обычно это не реализовано). Но я вот в своём проекте читалки rss это реализовал. У меня там обычный страничник снизу (обратный) и можно вернуться на любую страницу, но при чтении оно само подгружается бесконечно.
Создаем кэшируемую пагинацию, которая не боится неожиданного добавления данных в БД