t
А если надо не просто последнюю страницу, а 5 последних, то 5 запросов в бд?
почему 5? один, который выдаст 5 элементов :)
Size: a a a
2020 March 11
t
курсор не останется прежним, вы просто сгенирууете новый курсор на данных предыдущего (при этом не надо будет ковырять записи в базе)
нет-нет, текущий курсор останется прежним. сгенерируется новый курсор для следующей страницы
t
но это уже такое
A1
почему 5? один, который выдаст 5 элементов :)
На странице по 10 элементов. Надо получается взять 0, 10, 20, 30, 40, 50 записи с конца, чтобы сгенерировать курсоры для каждой страницы.
P@
нет-нет, текущий курсор останется прежним. сгенерируется новый курсор для следующей страницы
мы об одном и том же
я просто со стороны клиента говорю. Ему в сторе надо будет уже по новым курсорам бегать, и уже новую коллекцию формировать.
А так да оба курсора рабочих.
я просто со стороны клиента говорю. Ему в сторе надо будет уже по новым курсорам бегать, и уже новую коллекцию формировать.
А так да оба курсора рабочих.
t
да, это равноценно тому, чтобы взять 0, 10, 20, 30, 40, 50 записей с начала, если сортировка обратима
t
мы об одном и том же
я просто со стороны клиента говорю. Ему в сторе надо будет уже по новым курсорам бегать, и уже новую коллекцию формировать.
А так да оба курсора рабочих.
я просто со стороны клиента говорю. Ему в сторе надо будет уже по новым курсорам бегать, и уже новую коллекцию формировать.
А так да оба курсора рабочих.
а, да, вы правы.
t
На странице по 10 элементов. Надо получается взять 0, 10, 20, 30, 40, 50 записи с конца, чтобы сгенерировать курсоры для каждой страницы.
нет ничего плохого в том, чтобы взять элементы по оффсетам в пределах одной транзакции
t
оффсеты работают хорошо, пока таблицу не обновляют в процессе использования этих самых оффсетов
t
если же сделать 5 раздельных запросов без изоляции, то да, оно может обновиться посреди этого всего, и будет фигня, которой и пытались избежать
A1
Запросы в базу могут быть не такими дешевыми. У нас куча работы с географическими данными и некоторые типы сортировок могут быть довольно затратными.
P@
У себя в алгоритме я вообще брал на одну запись больше из базы. Например, для first: 10 я тянул 11 записей чтоб убедиться что дальше есть записи для hasNextPage. Последнюю запись отбрасывал и не возвращал клиенту.
t
Запросы в базу могут быть не такими дешевыми. У нас куча работы с географическими данными и некоторые типы сортировок могут быть довольно затратными.
понимаю и соболезную. в таком случае могу порекомендовать посмотреть в сторону концепции проекторов (read models)
t
это выделенные денормализаторы
A1
А если один запрос на 5 последних страниц и на странице 1000 элементов, то уже как-то слишком много из базы берется для простой пагинации...
t
которые используются только для чтения (и никогда для мутаций)
A1
У себя в алгоритме я вообще брал на одну запись больше из базы. Например, для first: 10 я тянул 11 записей чтоб убедиться что дальше есть записи для hasNextPage. Последнюю запись отбрасывал и не возвращал клиенту.
+
t
У себя в алгоритме я вообще брал на одну запись больше из базы. Например, для first: 10 я тянул 11 записей чтоб убедиться что дальше есть записи для hasNextPage. Последнюю запись отбрасывал и не возвращал клиенту.
мы для этой цели просто возвращали общее количество записей
t
но можно и по вашей методике
A1
понимаю и соболезную. в таком случае могу порекомендовать посмотреть в сторону концепции проекторов (read models)
Спасибо. Почитаю.