докер сам будет перезапускать если ему сказать
может запускать сколько угодно копий
просто скажите ему сколько надо

нет, но в симфочате точно есть

тут я проверяю ифом
if ($repository->findOneBy(['name' => 'ServerVersion']))
       {
           $serverVersion = $repository->findOneBy(['name' => 'ServerVersion'])->getValue();
       }

еще накину docker-compose up —scale на дев машинках можно, если у вас compose на проде - нельзя.

а сколько запросов пойдет в базу с сим чудом?

ок, понял, спасибо за ответы. без желчи бы еще, конечно, но как повезет))

два

Ловил его на двунаправленной связи. Но они, как известно, не нужны. Лишние джойны на геттерах только ловишь.

Да, точно, на двунаправленной

Всем привет)
подскажите, пожалуйста, как можно в контроллере понять, какой именно voter будет вызван из this->denyAccessUnlessGranted().
В проекте их очень много, и руками буду очень долго понимать по условиям.
sf 2.8

А можно поинтересоваться - а нахера это знать в контроллере?

для дебага)

А в дебаг-панели они вроде отображаются, не?

Раз уж зашел разговор про voters, какой правильный кейс их использования?
Вот допустим есть command/handler . Задача - редактирование только своей записи.  Это выходит надо запись получить в контроллере и пропихнуть ее в voters, прежде чем запускать handler? Не перегружается ли контроллер такими действиями?
Т.е. мы начала получаем запись по ID из репо, а потом ID запускаем в хэндлер и снова тянем из репо. Т.е. делаем это 2 раза. Это хорошо что у нас там IdentityMap, и нет лишних запросов.

Все будут использоваться по очереди. Ставь точку остановки в контроллере и ныряй.

а ты в курсе что можно сразу entity закинуть в isGranted/denyAccessblabla и не мучаться

да, спасибо, так и сделал :)

Так я об этои и говорю, что Entity надо достать, и делать это в контроллере.

Всем привет. Немного не по симфони, но попробую попросить помощи.
подскажите по событиям, которые генерирует сущность во время своей жизни. Сейчас у нас сделано через трейты+интерфейсы, типа $this->notify(new ShitHappens($this)) и потом postFlush события берутся через $еntity->publishEvents() и бросаются в диспатчер.
Есть ощущение, что уйти от трейтов и хранения событий в сущности было бы правильно. но возникает вопрос - как генерировать и отдавать в мир события?
Для их генерации нужно, чтоб "генерилка" их сторедж событий были либо внутри обьекта, либо приходили снаружи.
Если внутри - трейты, наследование, инжект, создание. Трейты дичь, наследование сущностей от BaseEntity - тоже, инжект - непонятно кем, как и когда. Создание какого-то eventEmiter'а внутри конструктора? Вызов статического метода EventService::foo(new Event)? Но тогда нужно как-то привязывать событие к конкретной сущности.
А если сторадж приходит снаружи, то добавление зависимостей к каждой операции, которая приводит к событиям (включая конструкторы) - тоже дичь.
Как быть, куда бежать?
Или я осел, зря парюсь и трейты норм ход в таком раскладе?

ну э да, достал в контроллере, чекнул права через isGranted или сразу кидаешь исключение через denyAccessUnlessGranted.
собственно, в документации же это и описано как кейс их использования.

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