А вот тоже вопрос, я джоинил связанные сущности в qb, но коллекцию связанной доктрина все равно тянула по одной кучей запросов, что посмотреть по этому вопросу?

Агааа попался

Хехе

Добавить в селект еще надо

Ну на то и есть инфо по количеству кверей)

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

Агааа попался

Да) я в симфе баклажан((( мало ещё работал.

или bulk-апдейты весело делать, или апсерты

Добавить в селект еще надо

Вторую связанную сущность получается?

ОРМ девопсу не друг )

где-то у меня был список претензий к орм, чисто для срачей

Вторую связанную сущность получается?

Да. Иначе онг её не сгидрирует

ОРМ девопсу не друг )

да какой я девопс, я так, палочкой в них тыкаю

Типа select([User::class, Skill::class])?

Select post, tags

Join post.tags tags

Вроде так я уже не помню )

Вроде так я уже не помню )

Понял) спасибо, дальше разберусь)

За меня давно уже копайлот пишет

)

Короче да мало приджоинить надо еще выбрать

За меня давно уже копайлот пишет

Оно что-то внятное писать умеет? Я думал по сути просто заменяет гугление и копипасту с гитхаба/стаковерфлоу?

Бэз понятия. Я больше верю в ноукод чем в копайлот

Как по мне безперспективный проект

А вы видел фичу? Я только сейчас заметил?

Привет! Подскажите, команды, eventSubscriber'ы и тд могут содержать в себе бизнес логику? Или правильнее всю бизнес логику держать в сервисах и вызывать из команд?

Привет! Подскажите, команды, eventSubscriber'ы и тд могут содержать в себе бизнес логику? Или правильнее всю бизнес логику держать в сервисах и вызывать из команд?

Правильнее второе, но обычно происходит первое

В таком случае получается достаточно много сервисов, которые в свою очередь обращаются к репозиторию. А репозиториев для одной сущности тоже можно делать много? Если да, то по какой логике их разделять?

В таком случае получается достаточно много сервисов, которые в свою очередь обращаются к репозиторию. А репозиториев для одной сущности тоже можно делать много? Если да, то по какой логике их разделять?

а почему их нужно делать много? ( репозиториев)

Очень большой репозиторий получается)

В таком случае получается достаточно много сервисов, которые в свою очередь обращаются к репозиторию. А репозиториев для одной сущности тоже можно делать много? Если да, то по какой логике их разделять?

Репозиторий должны содержать только простые методы

Репозиторий должны содержать только простые методы

Если мне нужна специфическая выборка из нескольких таблиц, то это куда?

Если мне нужна специфическая выборка из нескольких таблиц, то это куда?

В квери провайдер

В квери провайдер

а это что за зверь? гугл ни в паттернах, ни в целом по поиску сходу ничего внятного не даёт.

точнее немного ноги обнаруживаются в DAO на Java. Оно?

а это что за зверь? гугл ни в паттернах, ни в целом по поиску сходу ничего внятного не даёт.

Просто провайдер которые возвращает данные

Не знаю почему репозиторий должен содержать только простые методы

Где это написано ?

Просто провайдер которые возвращает данные

Можно пример? А то я тоже добавляю выборку из нескольких таблиц в репозиторий.

у нас простые запросы, которые можно через queryBuilder сделать, лежат в репозитории, а сложные, в Storage'х. Там SQL через executeQuery и маппинг через ResultSetMappingBuilder

Не знаю почему репозиторий должен содержать только простые методы

Репозиторий глупое хранилище collection like

команды и их хендлеры, в которых логика записи

запросы и их хендлеры в которых можно EntityManagerInterface прокинуть и достать оттуда репозиторий и сделать нужный запрос либо через dbal

Можно пример? А то я тоже добавляю выборку из нескольких таблиц в репозиторий.

class AccountDataProvider { public function getActiveAccounts(): array { $qb = $this->em->createQueryBuilder ....... query with multiple joins return $db->getResult() } Как пример

Привет всем! А кто юзает сонату админ, можете подсказать: простой кейс - надо добавить в меню вложенную группу ну, то есть, есть некая сущность, которую я помещаю в меню с условной аннотацией: tags: - { name: sonata.admin, model_class: App\Entity\Post, manager_type: orm, group: 'Content', label: 'Post' } Как проще сделать еще одну виртуальную группу внутри группы Content ? Чтобы в меню это выглядело так Content->Somethingelse->Post

Добрый день, сталкивался кто с проблемой бесконечных джобов в event listener'е доктрины, которые вызывают события event listener'a, которые в свою очередь, запускают заново джобу (от того и бесконечный цикл выходит)? То есть у меня задача такова: надо по update событию event listener'а запушить определенную джо,у, меняющую этот же объект на который навешаны события. Есть ли какие-нибудь решение такой проблемы? На ум лишь приходит сохранение стейта в кэш, а в очереде уже проверять

Есть решения

А поточнее?

Если есть рекурсия нало во-первых подумать про бейс кейс и условие остановки

Например посмотреть ченджсет

Может ты можешь не выполнять что-то если в ченджсете нету чего-то

Может ты можешь не выполнять что-то если в ченджсете нету чего-то

Ну вот Я про этот стейт и имел в виду: в кэше

Ну у тебя будут два разных ченджсета

Джобу я так понимаю можно запустить только если что-то там в ченджете конкретно есть

Или чего-то нет

не, в любом случае

Изменилось любое поле, пушим очеередь

А что меняет джоба?

Синхронизация с другой системой таким образом реализована, которая немного поля ентити

А что меняет джоба?

Сам ентити, а точнее его поля

Архитектурно что-то не то как по мне

И мне нужно на каждое события update'а эту джобу пропушивать

Заведи статик поле

Костыль но сработает

Типо джова отправлена

Архитектурно что-то не то как по мне

ну, иного ничего не придумал :/

Есть другой способ

Раньше в сервисах это дело было, и оно вызывалось на каждом методе, который апдейтил стейт ентити

Но он тоже на грани костыля

Заводишь хелпер а который ты добавляешь колбеки в очередь, сам хелпер выполняет их после флаша

хым

Но нарушается атомарность

Видимо будет тогда разумнее обратно вернуть эту логику в сервисы. Если только чего не придумаю

Спасибо за ответы

Всем привет. Кто-нибудь приложение разворачивает в кубернетисе? Нужно запустить unit тесты перед выкаткой приложения. Но девопс упёрся и говорит что APP_ENV=dev/prod и параметр —no-dev в composer должен быть единым. Ссылается на Twelve-Factor App. На моей памяти деплой был таким: 1) Предустановка, линтеры и всё таке 2) Запуск тестов (APP_ENV=test или dev) 3) Если успешно, тогда APP_ENV=prod и composer —no-dev Мож что-то новое придумали, а я как старовер пургу несу?

тестить код надо, а не контейнер

А можно более развёрнуто?))

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

Коллеги, а подскажите плиз сирому про доктрину. Вот есть сущность, в ней коллекция сущностей, а в той коллекции еще коллекция сущностей. везде cascade={'persist'} указано. Если я в первой коллекции добавляю-удаляю что-то, то все в БД сохраняется, а вот если во второй - то изменения игнорятся. ЧяДНТ?

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

Ну... Тогда схема будет такой? 1) контейнер тестов: - Предустановка, линтеры и всё такое - Запуск тестов (APP_ENV=test или dev) 2) Контейнер прода: - Предустановка, линтеры и всё такое APP_ENV=prod и composer —no-dev

чую что доктрина при добавлении во вторую коллекцию, почему-то считает что элемент первой не изменился, как заставить ее это понять?