ИИ
с другой стороны раз есть пармеры в start() - почему не сделать зеркальный update()
Size: a a a
2020 October 18
ML
ну опции init это не совсем code change, тебе нужна возможность обновить стрейты для перезапуска - это вроде понятно как, а вот с передачей обновленных параметров уже не очень понятно - ведь протокол детей не знает о том, что он в супервизоре. да и вообще параметры это уже прикладная часть
есть простой и понятный способ: отдать в ген-сервер обновленные параметры и сказать ему: или приведи себя в соответствие с ними, или сдохни.
Отмазки вида «это прикладная часть» делают попросту непригодным экосистему для мягкой реконфигурации
Отмазки вида «это прикладная часть» делают попросту непригодным экосистему для мягкой реконфигурации
V
не проще в ините генсервера считывать параметры по айди, а маппинш вынести в таблицу?
V
для изменения без рестарта - соответствующее апи у генсервера + апдейт маппинга
ML
не проще в ините генсервера считывать параметры по айди, а маппинш вынести в таблицу?
Возможно конечно и проще, но это все выглядит как костыль и нагромождение глобальных переменных, которые особенно раздражают тем, что в целом то все вокруг достаточно неплохо выдерживает концепцию зависимости от входных параметров
ML
Те ты предлагаешь перед запуском процесса не забыть положить в какое-то интересное место его настройки
ML
Точнее его стартовые параметры
V
у тебя тут сложность в том, что ты хочешь апдейт изменений без рестарта, но использование супервизора таким образом - подразумевает рестарт
ML
у тебя тут сложность в том, что ты хочешь апдейт изменений без рестарта, но использование супервизора таким образом - подразумевает рестарт
Ну так не надо воспринимать недописанность супервизора как догму!
V
я не говорю что это догма) я говорю что на мой взгляд ты хочешь чего-то специфического =)
ML
У supervisor нет даже такой простой штуки, как find_child
V
т.е. ты хочешь апдейт параметров не через init генсервера. но использовать при этом механизм, который вызывет init
ML
я не говорю что это догма) я говорю что на мой взгляд ты хочешь чего-то специфического =)
Ну да. Я хочу чтобы программа меняла конфигурацию без рестарта и повсеместных глобальных переменных
jc
надо переписать супервизор
jc
может написать свой
V
даже если бы супервизор такое предоставлял бы - всё равно патчить gen_server на поддержку апдейта без рестарта
V
или ты хочел code_change заюзать?
ИИ
есть простой и понятный способ: отдать в ген-сервер обновленные параметры и сказать ему: или приведи себя в соответствие с ними, или сдохни.
Отмазки вида «это прикладная часть» делают попросту непригодным экосистему для мягкой реконфигурации
Отмазки вида «это прикладная часть» делают попросту непригодным экосистему для мягкой реконфигурации
ну как отмазки - поведение по-умолчанию для init нет поведения, а для update придется делать. или обязать всех реализовывать заглушку. вроде не очень разумно, если можно решить кастомным сообщением вопрос
вот с супервизором да - можно подумать
вот с супервизором да - можно подумать
V
Я вот наконец-то понял как мне не хватало gen_server:check_response/gen_server:send_request который завезли в otp23. Очень удобно получается для пропертибейз тестирования.
DZ
ну как отмазки - поведение по-умолчанию для init нет поведения, а для update придется делать. или обязать всех реализовывать заглушку. вроде не очень разумно, если можно решить кастомным сообщением вопрос
вот с супервизором да - можно подумать
вот с супервизором да - можно подумать
В OTP, вроде, уже несколько мест с опциональными коллбеками (первым в голову пришло format_status)