The reason is that bundles shouldn’t rely on features such as service autowiring or autoconfiguration to not impose an overhead when compiling application services.
grabbee, ну вот для этого создаете отдельный проект, генерируете там сущности и переносите в бандл.
Autowire в бандлах крайне не рекомендуется, т.к. очень сильно влияет на производительность (https://symfony.com/doc/current/bundles/best_pract...)
grabbee, вероятно вам посоветовали создать проект для ручного тестирования, а не для unit-тестов.
Вообще в экосистеме есть куча бандлов, можно посмотреть как сделано у других. К примеру вот: https://github.com/BoShurik/TelegramBotBundle
nnkrasovok,
Во-первых, вопрос непонятен. Что значит в "в бд записывается только вариант ответа, который верный"? У вас в is_true будет true, если radiobutton отмечен, и false иначе. Что из этого не записывается?
Ну и теоретически у вас radiobutton не объединены в одну группу (name должны быть равны), так что они сейчас себя ведут почти как чекбоксы (только нельзя снять выделение). Вы их js-ом обрабатываете?
grabbee, нет, тут вопрос проектирования. Представьте, что у вас API и 100500 клиентов с мобильными приложениями. Как вы заставите их всех разом обновится? При разработки вашего API надо сохранять обратную совместимость. Так и в вашем сервисе. Надо чтоб работали старые и новые Message.
Я так понимаю у вас что-то вроде сервиса отправки, к примеру, SMS и клиенты, которые этим пользуются? Я бы выделил еще отдельный пакет, который бы использовался как клиент к вашему сервису. Т.е. не просто Message туда запихнуть, а прям всю работу по отправке сообщения, где под капотом бы уже использовался symfony/messenger
grabbee, ну если вы добавляете поле id, то проблема не сколько в отсутствии поля в сообщении, сколько в том, что это поле не будет обрабатываться всеми 1000 сервисами, пока вы их не обновите
