S
Size: a a a
2021 February 21
C
Привет. Есть две сущности Contracts и Options. Нужно между ними создать две связи manytomany. Например options и myoptions. В options будут храниться данные по одному условию, в myoptions по другому. Проблема в том, что когда добавлю второе поле и делаю make migration, выскакивает ошибка: The table with name 'contracts_options' already exists. Можно ли как-то по нормальному задать другое имя этой таблицы?
Если в вашем домене это оправдано, то можно через sti сделать 2 разных класса options (будут жить в одной таблице) и вязать ваши контракты на них по отдельности.
2021 February 22
j
Нашел чтобы использовать переменные .env из нужно их присвоить параметру в service.yaml. Мне каждый раз на каждую глобальную переменную делать запись в services для того чтобы потом можно было в коде использовать ?
SP
jenia
Нашел чтобы использовать переменные .env из нужно их присвоить параметру в service.yaml. Мне каждый раз на каждую глобальную переменную делать запись в services для того чтобы потом можно было в коде использовать ?
зачем? можно просто делать
Но я вот ленивый и юзаю просто при определении сервиса
%env(MY_PARAM). Проблемы с таким способом начнутся когда больше чем в одном месте юзается, когда всякие преобразования надо делать и тд. Просто удобнее отделить.Но я вот ленивый и юзаю просто при определении сервиса
D🦆
зачем? можно просто делать
Но я вот ленивый и юзаю просто при определении сервиса
%env(MY_PARAM). Проблемы с таким способом начнутся когда больше чем в одном месте юзается, когда всякие преобразования надо делать и тд. Просто удобнее отделить.Но я вот ленивый и юзаю просто при определении сервиса
Я думаю, что он это и имел ввиду.
AC
Можно же просто сделать сервис по работе с ЕНВ, если например тебе нужно в коде взять переменную, без использования DI. Как сделано с реквестом.
DK
Зависимости должны инжектиться снаружи, а на запрашиваться внутри из абстрактного сервиса провайдера переменных окружения.
DK
Здесь ситуация аналогична сервис локатору / DI. При всех плюсах последнего
ПГ
Зато, уровень абстракции выше. А то я как в ларавеле вижу чистый вызов env() прямо в сервисе - тихо грущу.
Там дело даже не в абстракции, а что если через env юзать - то есть прямые последствия, даже в доке есть пометка . Поэтому в Ларавел да, это грусть. А с симфони - норм, так как кроме единой точки с преобразованием в env препроцессоре и возможности работать через параметрбаг - минусов и грязи нет.
👤U
Там дело даже не в абстракции, а что если через env юзать - то есть прямые последствия, даже в доке есть пометка . Поэтому в Ларавел да, это грусть. А с симфони - норм, так как кроме единой точки с преобразованием в env препроцессоре и возможности работать через параметрбаг - минусов и грязи нет.
В ларавеле можно и нужно сделать правильно. Енвы получать в конфиг, а уже оттуда тащить в сервисы.
ПГ
Чем глубже сервис интегрирован с фреймворком тем хуже для сервиса.
Причем тут интеграция...
Можно и в ларавеле передать снаружи или через env() или через config() и сервис вообще не удет зависеть от фреймворка. Только при env - возможно в дальнейшем краш, а при config будет все норм.
Можно и в ларавеле передать снаружи или через env() или через config() и сервис вообще не удет зависеть от фреймворка. Только при env - возможно в дальнейшем краш, а при config будет все норм.