email из entity User):public function getEmails()
{
return array_column($this->getEntityManager()
->createQuery('select u.email from User u')
->getResult(\Doctrine\ORM\Query::HYDRATE_SCALAR), 'u_email');
}public function getEmails()
{
return array_column($this->getEntityManager()
->createQuery('select u.id, u.email from User u')
->getResult(\Doctrine\ORM\Query::HYDRATE_SCALAR), 'u_email', 'u_id');
}canExecute(), посмотрев в который можно заметить что он контролируется флагом --no-interaction. Более того, банально вызвав help по этой команде можно было бы увидеть ответ на свой вопрос написанный прямым текстом:Or you can also execute the migration without a warning message which you need to interact with:
bin/console doctrine:migrations:migrate --no-interactionConsoleTester о котором говорится в этом разделе, то видно что основная идея - использование специального input'а. Таким образом решение становится довольно простым: KernelApplicationArrayInputbin/console самой Symfony. symfony/framework-bundle, посмотреть его можно в соответствующем репозитории. src/Kernel.php вашего проекта и добавлен он туда именно через recipe. TokenInterface) и большинство частей Security компонента достаточно абстрактны для того чтобы из них можно было собрать весьма разнообразные схемы разделения прав доступа.Security::isAllowed()? Symfony по-умолчанию реализует первый подход, но ничто не мешает вам организовать собственную реализацию основных компонентов. Если вам нужен ACL (а именно так называется "привязка привилегии к функционалу") - то эта функциональность вынесена в отдельный ACL bundle в Symfony 4, скорее всего именно она вам и нужна.Content, в этом случае можно было бы запрашивать репозиторий именно для базовой entity и дальше у вас не будет разделения логики работы с теми же тегами.TagSearchService), сделать для каждого типа "category, faq, article" отдельные actions в их контроллерах которые будут обращаться к сервисному классу с разными (и в этом случае заранее известными) параметрами. Т.е., проще говоря, в каком-нибудь CategoryController::search() вы могли бы вызвать TagSearchService и передавать ему Category::class вместо того чтобы полагаться на приходящие извне данные. Если переходить на такую схему - то разные классы для элементов форм (CategoryType и FaqType в вашем примере) тоже естественным образом заменяются на один класс (какой-нибудь TagSearchType) т.к. между ними не остаётся различий. Кроме того не нужно будет передавать извне имя класса - по-моему это плохая идея в любом случае.TaggableInterface для entities которые могут иметь теги. Это естественным образом приводит к возможности в compiler pass собрать список таких entities и передать их в TagSearchService. Возможно потребуется для каких-то целей :)notIn(). Если же это и не так - код можно переписать с использованием array_map(), возможно это сделает его понятнее. Также findOneBy(['id' => $entityId]) очевидным образом меняется на EntityManager::find() что несколько проще выглядит.DiscriminatorMap который является правильным решением в данной задаче. Вам ничто не мешает теперь иметь в наследуемых классах отдельные свойства содержащие связи с конкретными entities, специфичными для каждого конкретного типа пункта меню. Вы также вполне можете объявить getEntity() / setEntity() в классе MenuItem абстрактными, а в дочерних классах реализовывать их. Конечно типы на уровне языка вам будет не задать, но никто не будет вам мешать использовать PHPDoc для создания type hints. ActivitableInterface для entities для которых есть флаг isActive) и дальше либо реализовать промежуточный абстрактный класс репозитория и наследовать custom repositories от него либо вынести эти операции в traits и подключать по мере необходимости.Command из symfony/command? Если да - то там есть раздельная инициализация через initialize(), туда передаётся OutputInterface и если сильно нужно - можно там вызвать некий отдельный сервис. Если не хочется прокидывать сервис вручную в каждую команду - можно автоматизировать это через setter + compiler pass либо через аннотицию @required /src кучу разных bundles, а иметь один общий код приложения, зависимый только от внешних packages (пусть даже написанных вами) которые устанавливаются через Composer.var/cache, там будет обычный setLogger($this->get('logger')) или что-нибудь типа этого. /usr/local/php или где он у вас расположен. EntryType на наследуемые entities через discriminator map, количество запосов это не снизит, но снизит количество join'ов и таблиц. Вот здесь можно подробнее почитать про него на русском.TranslatableEntityInterfaceStaticTranslatorProvider со статическим методом getTranslator(). В целом не очень хорошая идея, но работать будет