Как в случае паджинации по курсору решается проблема, если новые

элементы добавляют в список сверху? Скажем, ты переходишь на страницу, а за то время, что ты был на предыдущей, в список уже подобавлялись новые. И тогда сдвиг будет, рассинхрон, ты нажимаешь на 2-ую страницу, а по сути переходишь на какую-нибудь более далёкую (в зависимости от того, сколько элементов добавилось).

Этого никак не избежать

а вам это проблема? ну юзер полистает на 1 страничку больше, и что?)

То есть проще offset использовать в таком случае

Сброс состояния до актуального будет происходить на первой странице, получается?

Ну оффсет хуже, там можно в середине пропустить тоже

хорошо, убедил, оба варианта говно, не буду делать никакую паджинацию))))

знаю что на высоконагруженных штуках где лимит/оффсет не катят, то просто используют autoincrement id

Ну в целом так и есть - пагинация проблематична как не крути

это позволяет использовать только один фиксированный порядок

Делаешь запись в базе к которой записываешь id результатов, пока юзер ходит просто бегаешь по этой записи с пагинацией. Когда он приходит на первую страничку или проходит таймаут сбрасываешь значения?

А не знаешь, если сначала использовать обычный оффсет, потом будет не сложно поменять на более эффективный вариант? По идее просто сам запрос поменять, структуру бд менять не нужно, то есть выкатить такое изменение в проде будет не сложно поэтому, заранее, навернео, не имеет смысл загоняться

Как я вижу

ты сеьёзно для каждого пользователя предлагаешь на сервере ввести состояние, чтобы сохранять паджинацию отдельно для каждого? 😂😂😂

типа запоминать айдишники которые были выведены юзеру при выборке, правильно понял?

Ага

Нет, но это вариант как сделать это с минимальными затратами. Обычно похуй на такое

ну такое, имхо больше запаришся с оптимизацией этого чем с решением на лимите или айдишниках

а какую ты базу используешь? в postgress + typeorm это решается через .skip() .take() это если мы говорим про простую пагинацию

> skip ... take > обёртка для offset ))))))))

>typeORM Фу, брось каку, брось

почему каку

ну я не думаю что там настолько все просто. А typeorm стоит у меня по дефолту во всех проектах, в том числе и рабочих (ентерпрайз приложения). Есть проблемы конечно, но это самая функциональная orm. И да это именно ORM а не просто кверибилдер. Пилишь энтети, все строго типизированно, плюс тайпскрипт. А если взять еще какой нибудь NESTjs то ощущения как будто под spring кодишь, но с меньшей попаболью

> тайпорм стоит у меня по дефолту на всех проектах сочувствую

>все строго типизированно, Ох, не начинай...

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

> Всё строго типизировано https://www.prisma.io/docs/concepts/more/comparisons/prisma-and-typeorm

А я пишу nestJS + prisma, ощущения космические

хм, ну может попробую в каком нибудь pet проекте. спасибо! а как nest интегрируется с ней? примерно также? и главный вопрос дня, есть ли у нее сидеры?

хахах, это только выглядит призма так круто со стороны

У меня вообще никаких проблем не было, ток версию тайпскипта нужно обновить до последней. >сидеры Есть

ну, это я про призму саму

Найс, возможно будет стоить рассмотреть переезд на следующей итерации. Плюс было бы интересно заюзать ее в связке с GraphQL и посмотреть будет ли это работать. Думаю будет. По крайней мере причин почему не должно я пока что не вижу