Пагинация - правильно ли я делаю?

Так а в чём проблема, просто на последней странице показываешь остатки.

А вообще я бы предпочел чтобы на последней странице всегда было число постов, равное count_per_page. Благодаря этому часть постов попадёт с предпоследней страницы на последнюю, пока она не заполнится. А то бесит когда оставляешь пост, который оказывается заканчивает текущую страницу, а ледующий пост создаёт новую и твой пост уже мало кто увидит.

По-моему пагинацию так ещё никто не делал, а зря.

Так а в чём проблема, просто на последней странице показываешь остатки.

Ну так я и написал, что добавляется еще одна страница с остатками.

Я вообще про сам способ. Так ли вообще делается, или делает ли кто-нибудь так вообще.

Спасибо

Еще один тупой вопрос: а для чего двоеточие в последней строке?

Это слайс.

А, точно, спасибо большое. Забыл про его существование.

Ты лучше с пагинацией в процессорах разберись. Тут у нас очередные Спектры.

divmod() — это даже не стандартная библиотека, это builtin.

номер страницы умножать на количество записей на странице.

И что это даст фактически? Представь что ты выводишь на странице по две записи, у тебя в базе лежат записи с id 1, 2, 4, 8, 16, 32. Как ты будешь разбивать это на страницы имея только номер страницы и количество записей? Тебе нужно хранить последний айдишник на странице, и уже от него считать лимит этот, при этом не по айдишникам, а по количеству записей. Твой номер страницы это лишь метка о том, «сколько лимитов» надо пропустить прежде чем показывать очередную пачку записей.

Да, с этим у меня проблемы.

Учти, что limit/offset-пагинация отсасывает на большом количестве записей. Ну и страдает неправильной выдачей при вставке/удалении записей между запросами.

Я думаю, имелось в виду что-то вроде этого:

  select * 
    from my_table 
order by id
  offset (PAGE_NO - 1) * PER_PAGE 
   limit PER_PAGE;

Да, именно такое планировалось, но раз уж

limit/offset-пагинация отсасывает на большом количестве записей. Ну и страдает неправильной выдачей при вставке/удалении записей между запросами

То это так себе вариант.

То это так себе вариант.

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

Но если у тебя поле (или комбинация полей), по которому производится сортировка, содержит уникальные значения, то можно воспользоваться т.н. «keyset pagination» (или «cursor-based pagination», или «seek pagination»). Допустим, у тебя есть поле id, которое содержит уникальные идентификаторы записей, причем более поздней записи соответствует бОльший идентификатор (другой возможных кандидат — совокупность полей (created_at, id)).

Рассмотрим такую выдачу:

• id=42
• id=43
• ...
• id=51

Ссылка на предыдущую страницу будет иметь вид /my_table/list?before=42, а на следующую — /my_table/list?after=42 (название переменных запроса подберёшь себе по вкусу).

Запрос на получение записей для предыдущей страницы (тебе ещё нужно будет «развернуть» результат в БД либо в приложении):

  select *
    from my_table
order by id desc
   where id < 42
   limit PER_PAGE;

Получение записей для следующей страницы (для этого запроса «разворачивать» результат не надо):

  select *
    from my_table
order by id asc
   where id > 51
   limit PER_PAGE;

Естественно, нужен будет индекс по полю или комбинации полей, учавствующих в сортировке и выборке через where.

Недостаток этого метода — ты можешь переходить только на следующую/предыдущую страницу, но не на произвольную страницу (страницу с номером N).

Большое спасибо

Это годится для бесконечной прокрутки, а там где записи укладываются по порядку и не поднимаются все же от offset не убежать.
Я еще люблю подобный метод в комбинации с апи курсорами(не путать с курсорами БД), где API отдает некий не долгоживущий идентификатор в качестве курсора.
Есть такой вариант запрашивать id всех записей и потом как отдельными чанками их загружать. Это довольно-таки быстро выходит, но опять же не везде применимо.

а там где записи укладываются по порядку и не поднимаются все же от offset не убежать.

Можно тут поподробнее?

Например как здесь, внутри темы. Посты идут один за другим и не поднимаются/опускаются.
В то же время в трекере темы наоборот часто меняют позицию(грубо говоря бампаются).

Не вижу, что мешает использовать keyset-пагинацию в обоих случаях (положим, что нам не нужна операция «переход на произвольную страницу»).

Если не нужна то да, но еще могут быть проблемы с тем чтобы обратится к элементу напрямую по ссылке.
Можно обойти эти проблемы запрашивая все идентификаторы постов в треде, таким образом мы сможем свободно переходить к посту/отрезку в дискуссии. Конечно этот вариант без жс не реализовать, но в целом он иметь право на жизнь.
Так например поступает discourse и его клоны.