DZ
сделай explain plan
Size: a a a
2019 December 17
ВБ
и индекс именно на desc сортировку сделан?
ВБ
select * from
хотя индекс на updated_at стоит
topics order by updated_at desc limit 10 offset 385800 (2.1647 сек.)хотя индекс на updated_at стоит
я бы на твоем месте делал не оффсет, а что-нибудь типа where id > 100500
ВБ
тогда индекс можно будет использовать
NM
пагинирует нормально, но почему-то индекс на updated_at тормозит, на страницах после 50 тыс, поэтому я и хочу ограничить
Я статью на хабре вам скинул. Это проблема мускула
AG
тогда индекс можно будет использовать
В таблице могут быть пропуски id, это не надежно, но как вариант спасибо,
AG
Я статью на хабре вам скинул. Это проблема мускула
Ага читаю уже, спасибо
ВБ
В таблице могут быть пропуски id, это не надежно, но как вариант спасибо,
обычно не удаляют записи, а помечают как удаленные, что бы такой ситуации избегать)
DP
Переслано от Д Ф
#offtop Бля ребята только не умрите со смеху https://panorama.pub/28198-prezident-turkmenistana-pobedil.html
А жт не фейк?))
ДФ
А жт не фейк?))
Да эт просто панорама ))
d.
мускул тяжело офсетит если таблица там млн+.
d.
а что с хабром случилось ? эфективные дизигниры в деле
d.
а, это моб версия 🌝
DP
Да эт просто панорама ))
А, точняк! Не обратил внимания)
DP
Да эт просто панорама ))
Иногда реальность оказывается удивительнее выдуманных новостей 😆
S
Народ помогите разобраться когда нужно слать рефреш-токен:
Моя логика следующая - юзер открывает приложение, оно делает любой запрос к апи и получает ответ 401, токен протух, сразу автоматом шлёт ещё один запрос, но теперь с рефрешем, чтобы получить новую пару токенов. Верна ли логика? и как послать тот запрос от пользователя к апи, который сначала не прошёл, а теперь должен - дабы не просить пользователя повторять это действие.
Моя логика следующая - юзер открывает приложение, оно делает любой запрос к апи и получает ответ 401, токен протух, сразу автоматом шлёт ещё один запрос, но теперь с рефрешем, чтобы получить новую пару токенов. Верна ли логика? и как послать тот запрос от пользователя к апи, который сначала не прошёл, а теперь должен - дабы не просить пользователя повторять это действие.
АЧ
Народ помогите разобраться когда нужно слать рефреш-токен:
Моя логика следующая - юзер открывает приложение, оно делает любой запрос к апи и получает ответ 401, токен протух, сразу автоматом шлёт ещё один запрос, но теперь с рефрешем, чтобы получить новую пару токенов. Верна ли логика? и как послать тот запрос от пользователя к апи, который сначала не прошёл, а теперь должен - дабы не просить пользователя повторять это действие.
Моя логика следующая - юзер открывает приложение, оно делает любой запрос к апи и получает ответ 401, токен протух, сразу автоматом шлёт ещё один запрос, но теперь с рефрешем, чтобы получить новую пару токенов. Верна ли логика? и как послать тот запрос от пользователя к апи, который сначала не прошёл, а теперь должен - дабы не просить пользователя повторять это действие.
Ну проверь аяаксом перед отправкой запроса юзера
S
Ну проверь аяаксом перед отправкой запроса юзера
Вы представляете перед каждым действием отправлять ещё один запрос?
АЧ
Вы представляете перед каждым действием отправлять ещё один запрос?
ну ты весь кейс не описал, вообще стоит записать в локал стор дату потухания и все