E
Тоже как вариант
Size: a a a
2021 September 10
PE
Конфиг меняется, но мейлер то уже инициализирован со старым конфигом и живет себе
А
Один запрос. Если только у него не октан.
E
Октан это что?
PE
Или не очереди
E
Очереди уж)
А
Короче, вы неправильно решаете задачу: ни наследование, ни Config::set не нужен. Достаточно вспомнить, что Mailer — это не только фасад, а ещё сервис. Сервис можно инжектить в другой сервис, которому делегировать отправку почты, задав ему письмо и нужный конфиг подключения
А
И с очередями будет работать, и с октаном, если не юзать ебучие фасады
PE
Ты про MailManager говоришь
EG
скорее всего да, а MailManager есть extend() который позволяет свой транспорт сконфигурировать, вот я бы с этого начинал
А
Не надо. Это для ситуаций, когда число мейлеров статичное. А в рантайме конфигурировать новый мейлер глупо.
EG
в озвученной задаче все относительно статично, только конфиг лежит в базе
А
Конфигов может быть много
E
Ну любое решение подойдёт, там немного писем будет слаться, на восстановление пароля в основном и уведомления
E
Главное чтобы работало)
E
Актуальный один, но меняется в рантайме
А
Это то же самое, что слать уведомления на почту, указанную в базе. Вместо того, чтобы передать почту явно, вы заводите имя для неё в конфиге и через Config::set прокидываете в мейлер.
PE
Ну тогда читай конфиг с БД, переписывай через set и вызывай forgetMailers, после чего мейлеры пересоздадутся и перечитают конфиг, и ручками не надо ничего резолвить
E
Спасибо, позже попробую