Дело в том что использовать таблицы связи не охотно, и подсказали посмотреть на ArrayCollection, вот и разбираюсь

кто-то спутал теплое с мягким, arraycollection просто удобная обертка дял коллекция с плюшками

короче https://www.doctrine-project.org/projects/doctrine-dbal/en/2.8/reference/types.html#array-types

и если не хочешь использовать связи - зачем там https://gitlab.com/snippets/1760711#L20 ?

Спасибо за ссылку Имелось введу что нет желания создавать еще одну таблицу где бы хранить связи между сущностями, как в старинку)

Спасибо за ссылку Имелось введу что нет желания создавать еще одну таблицу где бы хранить связи между сущностями, как в старинку)

Json

@fes0r насколько много вещей ты позволяешь себе сложить в аргумент резолвер?

пример: есть сущность с довольно сложным началом жизни (нужно сходить в другую сущность за связанными полями и создать инстанс третьей сущности, хоть и не всегда) и у меня возникает выбор: либо по-максимуму подготовить все параметры в резолвере (про инстанциирование основной сущности речи не идет), либо делать все это в хендлере юзкейса (команды, суть остается та же)

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

если оно во многих местах одинаково юзается, то можно и впихнуть в резолвер

но я в хендлерах заполняю реквест сущностями

ну мест фактически два и больше не предвидится но я пока обошелся чуть иначе - первый смущающий пункт вынес в момент создания команды (там все равно нет внешний зависимостей, так что статический create хорошо сработал)

@fes0r насколько много вещей ты позволяешь себе сложить в аргумент резолвер?

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

но никаких ограничений у меня сейчас нету) разве что персист сущностей будет запашком))))

@fes0r привет, можешь, пожалуйста, скинуть гист про то как без орм миграции генерить?

https://gist.github.com/fesor/0d5ecf0afc638c7870272ead20614681

спасибо

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

бляха, тесты...

пример: есть сущность с довольно сложным началом жизни (нужно сходить в другую сущность за связанными полями и создать инстанс третьей сущности, хоть и не всегда) и у меня возникает выбор: либо по-максимуму подготовить все параметры в резолвере (про инстанциирование основной сущности речи не идет), либо делать все это в хендлере юзкейса (команды, суть остается та же)

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

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

ну короч, стремные вещи я обычно стараюсь выносить в стремный сервис)

https://gist.github.com/fesor/0d5ecf0afc638c7870272ead20614681

почему не делаешь такую годноту не приватной?)

у меня все закладки забиты урлами на твои secret гисты

done

мой лучший вклад в опенсорс, убедил фесора показать миру годноту

ну не все, мне надо гисты почистить

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

ну не все, мне надо гисты почистить

я просто поставил звёздочки на все твои полезные гисты)

Попробовал по гисту, но чет не выходит. Вообще ошибку выдает "The helper "entityManager" is not defined". Я полез дебажить и смотрю что такая ошибка вылезает, из-за вот этого куска кода: if ( ! $this->schemaProvider) { $this->schemaProvider = new OrmSchemaProvider($this->getHelper('entityManager')->getEntityManager()); } return $this->schemaProvider; И в этот момент действительно нету schemaProvider, хотя в services.yaml его прописал

в чем может быть проблема? куда ещё покопать можно?

при запуске команды попадаю в конструктор 2 раза, и во 2 раз schemaProvoder === null

портфолио говно

дизайн говно

что не так сделал - есть sti для пользователей, Admin extends User, Dealer extends User, дилер имеет проперти one-to-one@nullable=false, а при создании админа доктрина кричит что поле не заполнено, но ведь оно и не должно быть заполнено (т.к. оно в дилере)

ищи баг у себя

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

ну бля, давай конфиги и сщуности в гист кидай, мы ж не думбльдуры, чтобы понять че там у тебя

эх

где-то ты что-то криво настроил и оно создает диллера

а стой, это ж STI, даже не знаю что должно быть в этом случае

и как вообще доктрина хэндлит nullable false для такого.

глянь в сорс коде

https://gist.github.com/dmz9/1e4010697d699b9872892baf53a6fc3e

ты опять на пхп вернулся?)

я?

не

https://gist.github.com/dmz9/1e4010697d699b9872892baf53a6fc3e

он)

а

ты опять на пхп вернулся?)

дык я ж говорю, приходится и аппки пилить и бэкенды к ним )

https://gist.github.com/dmz9/1e4010697d699b9872892baf53a6fc3e

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

изи дебаг

потому что вроде на глаз все ок

хм ок ща

да, слушай с cti все четко, спасибо

скажи, а что ты будешь делать когда тебе надо будет сделать возможность что Dealer, Admin это один человек с одним аккаунтом?)

ну или любая другая роль в будущем

типа SuperPuperAdmin, Admin

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

ну лан)

да, это первое о чем мы думали, так то конечно бы не стал мутить наследование )

ну и CTI лучше подходит в этом случае

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

пока

что не так сделал - есть sti для пользователей, Admin extends User, Dealer extends User, дилер имеет проперти one-to-one@nullable=false, а при создании админа доктрина кричит что поле не заполнено, но ведь оно и не должно быть заполнено (т.к. оно в дилере)

вообще вроде логично выглядит, ты же сгенерил схему с nullable=false, значит там field NOT NULL, а оба типа объектов лежат в одной таблице. БД-то срать что у тебя там разные объекты =\

Всем привет. Скажите, кто-нибудь пользуется доктриновским методом flush с указанием entity? Как решаете в этом случае вопрос сохранения агрегата в репозитории, если он содержит вложенные entity ?

Всем привет. Скажите, кто-нибудь пользуется доктриновским методом flush с указанием entity? Как решаете в этом случае вопрос сохранения агрегата в репозитории, если он содержит вложенные entity ?

нет, он делает не то что ты ожидаешь.

нет, он делает не то что ты ожидаешь.

Нет, в смысле не пользуетесь?

Всем привет. Скажите, кто-нибудь пользуется доктриновским методом flush с указанием entity? Как решаете в этом случае вопрос сохранения агрегата в репозитории, если он содержит вложенные entity ?

основной вопрос - зачем ты вообще им пользуешься? 1. это устаревший функционал 2. он никогда небыл задокументирован 3. в 3-ей доктрине это дело удалят, в основном потому что flush с передачей конкретной сущности убивает всю идею UoW

Нет, в смысле не пользуетесь?

нет в смысле пользовался но там возникают проблемы — flush($entity) не сохраняет только один обьект. Он *считает* changeset только для одного объекта и потом пишет *все* изменения, которые были отложены

основной вопрос - зачем ты вообще им пользуешься? 1. это устаревший функционал 2. он никогда небыл задокументирован 3. в 3-ей доктрине это дело удалят, в основном потому что flush с передачей конкретной сущности убивает всю идею UoW

А в 3 доктрине будет какой-то механизм сохранения отдельно агрегата, а не всего, что есть разом?

Да у нас с коллегами возник вопрос, нужно ли его использовать (flush($entity)) . Тем более, что в третьей версии его удаляют. Вопрос возник из-за того, что flush сохранит все сущности, что добавлены через $em->persist. Если мы вызываем flush в репозитории, который предназначен для работы с одним агрегатом, то может ли возникнуть ситуация, что сохраняться и другие агрегаты, которые ты сейчас сохранять не хотел?

А в 3 доктрине будет какой-то механизм сохранения отдельно агрегата, а не всего, что есть разом?

а нафиг ты трогаешь больше одного агрегата ;)?

агрегат он собственно... граница транзакции)

но вообще да - будет. Типа table gateway. никаких changeset там не будет - ты типа соглашаешься что ты весь стэйт сохраняешь (что опять же как по мне только благо)

Да у нас с коллегами возник вопрос, нужно ли его использовать (flush($entity)) . Тем более, что в третьей версии его удаляют. Вопрос возник из-за того, что flush сохранит все сущности, что добавлены через $em->persist. Если мы вызываем flush в репозитории, который предназначен для работы с одним агрегатом, то может ли возникнуть ситуация, что сохраняться и другие агрегаты, которые ты сейчас сохранять не хотел?

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

я вот одного не могу понять — ORM по идее это приблуда, которая прозрачно сохраняет стейт твоих обьектов в БД и умеет стейт твоих обьектов из бд восстанавливать. Нафига сохранять по одному обьекту?

агрегат он собственно... граница транзакции)

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

я вот одного не могу понять — ORM по идее это приблуда, которая прозрачно сохраняет стейт твоих обьектов в БД и умеет стейт твоих обьектов из бд восстанавливать. Нафига сохранять по одному обьекту?

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

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

разные агрегаты - разные транзакции.

ну то есть разные БИЗНЕС транзакции

ты можешь обернуть это все в одну транзакцию в базе, если у тебя есть такая возможность

но рано или поздно с ростом проекта ты будешь больше прибегать к eventual consistency

ну или эти твои разные агрегаты - это все был один агрегат)

p.s. иногда можно просто перегруппировать стэйт и эти проблемы если и не исчезают, то сильно минимизируется ущерб

p.p.s. А еще есть компенсирующие транзакции, но это опять же ближе к eventual consistency

p.p.s. А еще есть компенсирующие транзакции, но это опять же ближе к eventual consistency

это что-то из мира саг?

это что-то из мира саг?

из мира потніх дедов

Саги да

по сути саги это всего лишь про менеджеры процессов (штуки которые принимают решения на основе доменных ивентов) + компенсационные транзакции

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

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

но разве просто flush не решает твоих проблем?) у тебя будут в одной тарнзакции сохранены 2 агрегата

ну бездумно в это лазить бесмысленно если у тебя одна БД (как у меня и у 99% тут)

после таких длинных монологов хочется взять и измазаться всеми этими словами по самые уши

тут не про количество баз данных

но разве просто flush не решает твоих проблем?) у тебя будут в одной тарнзакции сохранены 2 агрегата

Проблемы возникла из-за того, что один коллега в проекте в репозиториях сохраняет flush (entity ), можно сказать это новый проект . У нас мало опыта работы с доктриной, а другие разрабы увидели и говорят, что так делать не надо.

Я понял ваши ответы и советы.

в общем, не делай так, через пару лет можно отгрести труднообьяснимых проблем на ровном месте)