😂

😂

👍😁

Ещё по базе подокапываюсь - получается в AR всё так же link только ключи могут быть и нельзя замутить связь с подзапросом или  на массив типа  on t1.id = ANY(t2._array_column)

да

в этом плане ничего не переделывали

пока, в основном, касались db... AR мало

Ястно... но мои кейсы - это конечно уже малость извращения, но в целом чем мне понравился элокент ларковский - это как раз тем, что там каждый тип связи - свой класс, и гораздо гибче в том числе полиморфные связи мутить (в остальном - это тормозное г, конечно) и те же коллекции. (Я какое-то время ковырялась в них - но штука в том что с этим линк и hasOne - hasManyдаже в принципе код очень мутно-некрасивый получается - хотя и на нём тоже можно many2many синхронизацию вымутиь)

Если есть идея на что-то, хорошо бы оформить issue с описанием. А ещё круче её потом реализовать ;)

Ларовский илоквент и юишный AR очень похожи. Думаю можно вполне перенести в AR всë что есть хорошего в илоквенте.

Это уже три года как не так (с версии 3.4). ENV используется только в рантайме, при билде их не заюзать

Почему не заюзать?

Потому что контейнер билдится и больше не меняется. Если он будет зависеть от переменных окружения, то есть вероятность, что его надо будет пересобирать при изменении этих переменных, что неприемлемо

Ну, т.е. можно конечно заюзать $_ENV[‘var’] напрямую, но это костыль. Примерно такой же, как использовать $_POST и $_GET

Собираем приложение в контейнер:
1. Прокидываем переменные окружения
2. Ставим сорцы приложения
3. Делаем билд конфигоа
4. Запаковываем контейнер

Теперь с любыми переменными окружения конфигурация приложениях в контейнере не поменяется.

Мы же сейчас про симфони говорим?

Вот если нам надо поменять что-то в приложении, я должен просто изменить соответствующую переменную окружения, пересобирать при этом контейнер не надо. А если на этапе билда контейнера эта переменная используется, то все насмарку