dizzy7

Сделать раздельные конфиги для каждого коннекта, например raw.yml

name: Raw database migration
migrations_directory: "../../DoctrineMigrations/raw/main"
migrations_namespace: Application\Migrations
table_name: migration_versions

И запускать миграции с ключами
bin/console do:mi:mi --db=raw --configuration=app/config/migrations/raw.yml
Где --db=raw - имя connection в конфигурации доктрины

Вспоминая переход на 3-ю версию - основная проблема это поддержка бандлов. Для нашего проекта пришлось ждать больше года, пока все обновились. Подозреваю что с четвёркой будет похожая ситуация.

Был подобный переход, проще всего сделать так:

- обновить до 2.8, пройтись по всему сайту в дев-окружении, проверять функционал (скорее всего ничего не сломается), отслеживать в дев-панели deprecated, фиксить
- когда их не останется переходить на 3.4 и еще раз пройтись по сайту проверяя что всё ок

Отдельный сервис создавать не нужно. В конфигурации логгера:

monolog:
   channels: ["main", "search"]
   handlers: ...

И для логирования запрашиваете сервис @monolog.logger.search

В таких случаях обычно действует простое правило - если вы не понимаете зачем вам это нужно, значит оно вам не нужно =) В видео всё очень подробно и наглядно рассказано где это можно применять, если вам непонятно - значит у вас просто не было таких задач.

Когда-то у меня например была задача по обработке заявок. Около семи статусов со сложными условиями и возможностью перехода из статуса в статус - это как раз кейс для workflow.

Симфонивские формы очень удобны для больших статических форм. Если вы строите их в ангуляре, то проще обойтись без них - просто отсылаете на сервер json, десериализуете в entity, прогоняете через валидатор и сохраняете.

Если очень нужна привязка форм к поляем entity - можно сделать какой-нибудь сервис, который будет возвращать в json список полей entity и на их основе строить форму на фронте