мне казалось, что динамический это не RTT до клиента, а RTT до региона самого CF

т.е. клиент попадает на CF "европа" (грубо говоря, я не в курсе деталей), CF держит в кэше среднее время "сколько из CF европа до инстанса N RTT" и направляет большинство европейских клиентов туда. но, вероятно, не всех - замерять RTT до остальных инстансов же тоже нужно. в то время как чистый гео-механизм не делает никаких дополнительных assumptions, "чувак из германии? валит в европейский инстанс"

> фактически сработает как geo streeting, хотя он выключен
ну в общем да, ключевое отличие - не всегда, пушо надо мерять RTT на остальные инстансы

Гайз, хелп
Есть таблица с пользователями, надо его мигрировать в систему где для авторизации используется device. Пароли device compatible. Но как сохранить зашифрованный пароль? Если вариант кроме как обновлять поле через update_column?

Raw sql

Это не тупо копирование, поэтому не подойдет

а в чем проблема с паролем то? Это же колонка encrypted_password

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

Мы просто SQL писали

Пароли с солью переносили

Хорошо, спасибо
Значит update_column

Извините, но вопрос способа миграции не обсуждается 🙈

Нашла что хотела. Надо тупо обновить encrypted_password. И не скипать ни валидации ни колбэки

Выходит что либо берешь гео, но прилично платно, либо надежды и костыли.

В рамках CF конечно

Если прям серьезная геозавязка (например, немгновенная репликация клиентов разных регионов между инстансами) - да, все так

Можешь подробнее сказать что имеешь ввиду? Я учусь, не совсем понял тебя

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

Я с ним пока не решил, прикидываю и копаю.

там вы вроде на шардах остановились с Антоном. в случае с шардированием, если ты определяешь в какой шард чувака класть на основании региона инстанса, а не на основании выбора самого юзера, часть юзеров будут жить не в своих регионах - потому что CF не накопил достаточно данных о RTT. типа: юзер приходит из US, его закидывает в EU в рамках проверки RTT, и вот он уже в EU-шарде первично живет, и его нужно двигать