Потрясающая актерская игра. Контент в кайф, давай ещё. Спасибо за ссылки на другие конференции.
@UnitedFeodor
Ай бұрын
прекрасный доклад, спасибо
@Morgan_iv
9 ай бұрын
Если это новый проект, то проще заюзать UUIDv7 и не иметь головной боли с правильными множественными сортировками и индексами прямо с порога. Если проект старый и уже с сортировкой, то тащить keyset все равно больно, и притащить сразу UUIDv7 боли не добавит. Ну и если токен ещё и шифровать, то такое, во-первых, приличные люди могут посчитать трекером и удалить на всякий из урла, а во вторых пропадает возможность изменить размер страницы с фронта, или это будет выглядеть довольно глупо отдельным параметром
@kirillchug
7 ай бұрын
По поводу проблемы почему в конце происхоидт sql-запрос count() по всему. Это из-за того, что контракт Page JPA имеет в себе поле totalElements. Оно хранит в себе общее кол-во элементов, которое вообще доступно для пагинации. Этот параметр по дефолту во всех ui работает для вычисления кол-ва страниц. Поэтому и дефолтный контракт Page JPA подразумевает, что именно по totalElements в основном будет вычислени кол-ва страниц в таблице
@MaximBodrov
Жыл бұрын
Да, классное шоу! Infninte scrolling убедил меня в конечном счете )
@alexanderpodkopaev6691
Жыл бұрын
Спасибо! Подача прикольная. По содержанию - полезно, буду давать мидлам, чтобы не рассказывать каждый раз самому. Все как и 10 лет назад: чуть только БД больше курсовика, иллюзии "ORM все сделает само и будет быстро" отступают, и приходится изучать, как работает БД. Хотя бы раз, хотя бы тому, кто кастомизирует ORM.
@----1281
3 ай бұрын
Еще, count можно делать оконной функцией (window) вместе с выборкой данных, работает заметно шустрее
@MurikSan
8 ай бұрын
Случаи с добавлением - понятно, условная createDate будет ставить новые строки "в конец". А вот что будет происходить при удалении строки не очень понятно? Если делать логическое удаление - вопросов нет. Но опять же на больших таблицах одна из механик - это перенос "удаленных" в колд хранилище. ну или просто физ удаление. получится что логика сломается, или я чет не допонял.
@gordinmitya
Жыл бұрын
чуть-чуть кринжово, но потом кайф
@mickle-ak
Жыл бұрын
Тут не только переход по номеру поблематичный, но и листание назад неясно как делать... Опс... недослущал вопросы. Ответ - по сути никак. Ну и зачем тогда...
@iliasazonov4699
Жыл бұрын
Похоже я плохо на вопрос ответил. С получением предыдущей страницы нет проблем. Для получения текущей страницы мы передаём не бекенд значения колонок, идентифицирующие первую строку страницы и отсчитываем следущие 10 строк. А для получения предыдущей страницы нужно просто отсчитать предыдущие 10 строк. Чтобы это сделать, достаточно реверсировать сортировку. Так что делается просто, только надо немного покодить. Если кодить лень, то можно отсылать на фронтенд два токена - для получения следующей страницы и для получения предыдущей страницы
@bananasba
Жыл бұрын
Подача невыносимая
@iliasazonov4699
Жыл бұрын
Буду очень благодарен, если напишете, что особенно неприятно. Нам очень поможет
@bananasba
Жыл бұрын
@@iliasazonov4699 хотелось бы слышать четкую постановку проблемы и описание решений, а тут больше времени потрачено на реплики не по делу
@LeatherVladAU
9 ай бұрын
Мне понравилось, прикольно вышло
@arturbarkou6347
8 ай бұрын
Да неее, подача отличная, не скучно и все понятно
@abkvandrd
8 ай бұрын
@@iliasazonov4699 Актерская игра на троечку с минусом, шутейки не смешные, а главное, тут полезной информации на небольшую статейку-заметку на 10мин чтения макс., а тут аж на 45 минут видос. Вы же за оптимизацию топите ) Но все равно спасибо за доклад, я так в свое время доставал много данных из базы, гораздо быстрее чем offset, теперь знаю что это называется keyset )
Пікірлер: 18