По поводу проблемы почему в конце происхоидт sql-запрос count() по всему. Это из-за того, что контракт Page JPA имеет в себе поле totalElements. Оно хранит в себе общее кол-во элементов, которое вообще доступно для пагинации. Этот параметр по дефолту во всех ui работает для вычисления кол-ва страниц. Поэтому и дефолтный контракт Page JPA подразумевает, что именно по totalElements в основном будет вычислени кол-ва страниц в таблице
Спасибо! Подача прикольная. По содержанию - полезно, буду давать мидлам, чтобы не рассказывать каждый раз самому. Все как и 10 лет назад: чуть только БД больше курсовика, иллюзии "ORM все сделает само и будет быстро" отступают, и приходится изучать, как работает БД. Хотя бы раз, хотя бы тому, кто кастомизирует ORM.
Если это новый проект, то проще заюзать UUIDv7 и не иметь головной боли с правильными множественными сортировками и индексами прямо с порога. Если проект старый и уже с сортировкой, то тащить keyset все равно больно, и притащить сразу UUIDv7 боли не добавит. Ну и если токен ещё и шифровать, то такое, во-первых, приличные люди могут посчитать трекером и удалить на всякий из урла, а во вторых пропадает возможность изменить размер страницы с фронта, или это будет выглядеть довольно глупо отдельным параметром
Случаи с добавлением - понятно, условная createDate будет ставить новые строки "в конец". А вот что будет происходить при удалении строки не очень понятно? Если делать логическое удаление - вопросов нет. Но опять же на больших таблицах одна из механик - это перенос "удаленных" в колд хранилище. ну или просто физ удаление. получится что логика сломается, или я чет не допонял.
Тут не только переход по номеру поблематичный, но и листание назад неясно как делать... Опс... недослущал вопросы. Ответ - по сути никак. Ну и зачем тогда...
Похоже я плохо на вопрос ответил. С получением предыдущей страницы нет проблем. Для получения текущей страницы мы передаём не бекенд значения колонок, идентифицирующие первую строку страницы и отсчитываем следущие 10 строк. А для получения предыдущей страницы нужно просто отсчитать предыдущие 10 строк. Чтобы это сделать, достаточно реверсировать сортировку. Так что делается просто, только надо немного покодить. Если кодить лень, то можно отсылать на фронтенд два токена - для получения следующей страницы и для получения предыдущей страницы
@@iliasazonov4699 Актерская игра на троечку с минусом, шутейки не смешные, а главное, тут полезной информации на небольшую статейку-заметку на 10мин чтения макс., а тут аж на 45 минут видос. Вы же за оптимизацию топите ) Но все равно спасибо за доклад, я так в свое время доставал много данных из базы, гораздо быстрее чем offset, теперь знаю что это называется keyset )
![GEEK TIMË [OFFICIAL AUDIO]](http://i.ytimg.com/vi/ry-6RvkH880/mqdefault.jpg)
![Gunna - HIM ALL ALONG [Official Visualizer]](http://i.ytimg.com/vi/HiCxoDeo0hc/mqdefault.jpg)
![Chino Pacas - Modo Capone (with Drake & Fuerza Regida) [Video Oficial]](http://i.ytimg.com/vi/zjv8TQ0gBkg/mqdefault.jpg)
Потрясающая актерская игра.
Контент в кайф, давай ещё.
Спасибо за ссылки на другие конференции.
По поводу проблемы почему в конце происхоидт sql-запрос count() по всему. Это из-за того, что контракт Page JPA имеет в себе поле totalElements. Оно хранит в себе общее кол-во элементов, которое вообще доступно для пагинации.
Этот параметр по дефолту во всех ui работает для вычисления кол-ва страниц. Поэтому и дефолтный контракт Page JPA подразумевает, что именно по totalElements в основном будет вычислени кол-ва страниц в таблице
прекрасный доклад, спасибо
Еще, count можно делать оконной функцией (window) вместе с выборкой данных, работает заметно шустрее
Спасибо!
Подача прикольная. По содержанию - полезно, буду давать мидлам, чтобы не рассказывать каждый раз самому.
Все как и 10 лет назад: чуть только БД больше курсовика, иллюзии "ORM все сделает само и будет быстро" отступают, и приходится изучать, как работает БД. Хотя бы раз, хотя бы тому, кто кастомизирует ORM.
Да, классное шоу! Infninte scrolling убедил меня в конечном счете )
Если это новый проект, то проще заюзать UUIDv7 и не иметь головной боли с правильными множественными сортировками и индексами прямо с порога. Если проект старый и уже с сортировкой, то тащить keyset все равно больно, и притащить сразу UUIDv7 боли не добавит.
Ну и если токен ещё и шифровать, то такое, во-первых, приличные люди могут посчитать трекером и удалить на всякий из урла, а во вторых пропадает возможность изменить размер страницы с фронта, или это будет выглядеть довольно глупо отдельным параметром
Случаи с добавлением - понятно, условная createDate будет ставить новые строки "в конец". А вот что будет происходить при удалении строки не очень понятно? Если делать логическое удаление - вопросов нет. Но опять же на больших таблицах одна из механик - это перенос "удаленных" в колд хранилище. ну или просто физ удаление. получится что логика сломается, или я чет не допонял.
чуть-чуть кринжово, но потом кайф
Тут не только переход по номеру поблематичный, но и листание назад неясно как делать...
Опс... недослущал вопросы. Ответ - по сути никак. Ну и зачем тогда...
Похоже я плохо на вопрос ответил. С получением предыдущей страницы нет проблем. Для получения текущей страницы мы передаём не бекенд значения колонок, идентифицирующие первую строку страницы и отсчитываем следущие 10 строк. А для получения предыдущей страницы нужно просто отсчитать предыдущие 10 строк. Чтобы это сделать, достаточно реверсировать сортировку. Так что делается просто, только надо немного покодить.
Если кодить лень, то можно отсылать на фронтенд два токена - для получения следующей страницы и для получения предыдущей страницы
Подача невыносимая
Буду очень благодарен, если напишете, что особенно неприятно. Нам очень поможет
@@iliasazonov4699 хотелось бы слышать четкую постановку проблемы и описание решений, а тут больше времени потрачено на реплики не по делу
Мне понравилось, прикольно вышло
Да неее, подача отличная, не скучно и все понятно
@@iliasazonov4699 Актерская игра на троечку с минусом, шутейки не смешные, а главное, тут полезной информации на небольшую статейку-заметку на 10мин чтения макс., а тут аж на 45 минут видос. Вы же за оптимизацию топите )
Но все равно спасибо за доклад, я так в свое время доставал много данных из базы, гораздо быстрее чем offset, теперь знаю что это называется keyset )