Алексей Скобкин

Можно использовать expressions: https://symfony.com/doc/current/service_container/...

А можно подсмотреть как у Symfony сервисы подменяются в зависимости от того какая среда (EventDispatcher, контейнер, etc).

Что такое "не работает"?
Ну и вы же сами в примерах выше выключили автовайринг. Например, тут:

TwoBuilder:
    public: true
    ###
    autowire: false
    ###
    class: App\Builder\BuilderBase
    arguments:
      $file: '%kernel.project_dir%/public/files/two.xml'
      $mapping: '%two.mapping%'

Я, конечно, могу ошибаться, но подстановка аргументов по именам - это, вроде как, часть автовайринга.

Благодарю за ответ, но все равно такая же ошибка :С

Ещё есть мысль, что, скорее всего, ваши сервисы FirstBuilder и TwoBilder (правильно: SecondBilder) конфигурируются правильно (если опустить потенциальную проблему с передачей по именам без автовайринга), а ошибка конфигурации возникает именно с сервисом App\Builder\BuilderBase. Обратите внимание, что я имею в виду не класс, а именно ID сервиса. То есть, по факту у вас есть ручная конфигурация двух "виртуальных", если так выразиться сервисов и одна конфигурация дефолтного представления сервиса, которая создаётся автоматически (т.к. автовайринг и автоконфигурация включены глобально, чего вы не показали в вопросе, кстати).

Иными словами:
- Сервис FirstBuilder - валиден и конфигурируется нормально
- Сервис TwoBuilder - валиден и конфигурируется нормально
- Сервис App\Builder\BuilderBase - пытается конфигурироваться автоматически, но не может, т.к. для скалярных аргументов, массивов и всего прочего, что не сервис нужны либо биндинги дефолтных значений (см. services._defaults.bind)? Либо явная передача аргументов в написанном вами блоке конфигурации.

Так что вам, наверное, правильнее будет чтобы не выключать автовайринг глобально сделать один билдер дефолтным с ID сервиса App\Builder\BuilderBase дабы система не пыталась сконфигурировать ещё один сервис под этот класс, а второй билдер уже называть как вам угодно.

Вывод:
Читать про нововведения в DI после 3.3 (а лучше и про более поздние), осмыслять, рефакторить конфигурацию.

У Symfony есть документация на эту тему: https://symfony.com/doc/current/doctrine/multiple_...

А пример из реальной жизни можете посмотреть, например, у меня в этом мини-проекте. Там PostgreSQL и SQLite одновременно работают.
Внимание стоит обращать на config/packages/doctrine.yaml. Это, само собой, для заранее известных соединений.
Ну и для сущностей из каждой базы использовать свой EntityManager. Это в любом случае - не зависимо от того определены заранее или в рантайме подключения.

и сразу же ловлю ошибку что такой таблицы не существует в этой базе данных

Скорее всего, не тот EntityManager используете либо не с тем соединением его создаёте.

Ну вообще, вот здесь:

$this->getReference('main_user');
$article->setAuthor($author);

Вы забыли присвоить переменной $author результат получения референса, судя по всему.

А ещё я, наверное, странную вещь скажу, но дебажить очень хорошо можно с помощью дебаггера.

Возможно, но скорее всего, не очень хорошая идея.

Потому что для поиска похожих товаров, скорее всего, понадобится достаточно жирная логика, а может даже какой-нибудь поисковый движок или ещё что-нибудь - в зависимости от требований. А это уже надо делать в сервисе.
И что вы, чтобы не переопределять метод будете сервис в сущность запихивать?

As the Doctrine tools documentation says, reverse engineering is a one-time process to get started on a project. Doctrine is able to convert approximately 70-80% of the necessary mapping information based on fields, indexes and foreign key constraints. Doctrine can't discover inverse associations, inheritance types, entities with foreign keys as primary keys or semantical operations on associations such as cascade or lifecycle events. Some additional work on the generated entities will be necessary afterwards to design each to fit your domain model specificities.

https://symfony.com/doc/current/doctrine/reverse_e...

Просто создайте нужные сущности вручную.

Но обратите внимание на остальные ответы из того треда на SO. Лучше, конечно, не использовать view с Doctrine.

Доктрина создает сущности при помощи рeфлексии, в обход конструктора и сеттеров.

С помощью десериализации. (UPD: см. комменты, уже не актуально)

Видимо предполагается, что состояние, хранящееся в БД, всегда валидно. Но так бывает не всегда.

Это ваша задача этого не допускать. Если вы это допустили, ошибки Doctrine - это меньшее, что может вылезти.

Например, в БД есть nullable поле `name`, которое в сущности не должно быть nullable

Ну так может быть стоит привести схему и сущность с маппингом в соответствие друг другу, а не отстреливать симптомы?

public function getName(): string
и если в БД руками проставить null, то ошибка возникает только при запросе этого геттера.

Решается это так:
public function getName(): ?string

Я сначала было хотел вам предложить валидировать данные на входе в сущность (конструктор), но потом читая ваш вопрос дальше, понял, что вы вообще используете Doctrine очень странно и ждёте, что сама Doctrine будет вам предоставлять средства для ухода от возникающих проблем.
Первое и самое важное: Doctrine - это Data Mapper. Если у вас маппинг и сущность не соответствуют схеме - работать ничего нормально не будет. Лечите заболевание, а не симптомы.

https://packagist.org/packages/friendsofsymfony/re...
https://packagist.org/packages/api-platform/api-pack

Используя Flex можно не тащить все компоненты.

1. Посмотрите хотя бы код миграций для начала. Обратите внимание на условие if.
2. Обычно никто не держит в среде разработки и на продакшене разные СУБД.

api.symfony.com/4.0/Symfony/Component/BrowserKit/C...
?

Вы видели, что делает этот метод? Зачем вам для этого контроллер?

Ну вам же по-человечески написано, что нельзя сериализовать объект класса File. Ищите, где у вас сериализация происходит.

Начните писать на Symfony. Последний раз, когда я пробовал, это сработало.

https://packagist.org/search/?q=symfony%20dependen...

1. Включить голову, перестать надеяться, что на всё, что вам захочется есть готовое решение.
2. Написать логику чата, которая будет отправлять сообщения только тому, кому они адресованы.
3. Если хотите помощи с не работающим кодом - приводите код.