@symfony_ru - страница 586 - Telegram web archive

Andrei

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

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

Denis

доктрина поддерживает такой вариант, особо проблем не должно быть. https://www.doctrine-project.org/projects/doctrine-orm/en/2.13/reference/inheritance-mapping.html#inheritance-mapping

Павел

соответственно есть два разных агрегата из разных контекстов. но оба имеют в составе сущности, которые опираются на одну таблицу бд. Наводить микросервисную ересь с отдельными БД нет желания)

Звучит немного странно, два контекста, два агрегата, две сущности - а таблица одна.

Павел

А вообще вот закладка есть по этой теме, в добавок к доке: http://jstructure.com/post/doctrine-entity-extending/

Andrei

Звучит немного странно, два контекста, два агрегата, две сущности - а таблица одна.

почему нет. есть у тебя условно список брендов. id, name И есть контекст заказов и контекст закупок. и там и там этот список - тупо справочник названий. зачем плодить таблицы? А еще их как то синхронизировать потом

Andrei

А вообще вот закладка есть по этой теме, в добавок к доке: http://jstructure.com/post/doctrine-entity-extending/

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

Павел

почему нет. есть у тебя условно список брендов. id, name И есть контекст заказов и контекст закупок. и там и там этот список - тупо справочник названий. зачем плодить таблицы? А еще их как то синхронизировать потом

А нужен ли в логике (именно в логике) название бренда в обоих контекстах?

Павел

Я понимаю, что делать одну большую таблицу проще и не синхронизировать данные. Но true way - это как раз разделение

Павел

Чтобы таблицы были узкими, а контексты максимально независмыми

Павел

Я сомневаюсь что в хоть одном контексте название бренда участвует в логике

Andrei

Я сомневаюсь что в хоть одном контексте название бренда участвует в логике

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

Павел

@ejkot Еще варик забить на migration:diff )

The Ant

почему нет. есть у тебя условно список брендов. id, name И есть контекст заказов и контекст закупок. и там и там этот список - тупо справочник названий. зачем плодить таблицы? А еще их как то синхронизировать потом

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

Павел

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

diff падает при таком

The Ant

Я им не пользуюсь )

Павел

Я им не пользуюсь )

Ну вообще норм тема, некоторые подобные "хаки" открывает )

Павел

Не буду топить ни за ни против)

The Ant

Дактрина какое-то говно создоет в бд, если положится на ее генератор миграций. Лучше вручную писать.

Павел

Дактрина какое-то говно создоет в бд, если положится на ее генератор миграций. Лучше вручную писать.

Ну хз, зависит от сложности и правильности написания. В целом не жалуюсь, бывают баги, слышал. Работаю и так и так на разных проектах.

Павел

Зачастую "гавно" вылазит от непарвильности описания сущностей

Павел

Но вообще надо подстраиваться иногда, это да

Павел

Например one-to-one в обратную сторону хрен сделаешь, падает по констрейнтам. А без diff - вроде нет проблем

The Ant

Ну не. Индексы, параметры колонок всякие. Дефолтные значения. Все ебется как попало. Уже молчу что саму миграцию не прочитать порой

The Ant

Имена у индексов которые генерит доктрина вообще отдельный пиздец.

Павел

Имена у индексов которые генерит доктрина вообще отдельный пиздец.

Так имена можно ставить

Andrei

Я обычно генерю diff, а потом руками допиливаю

Юра

Может просто выбирать в нужное ДТО с одной таблицы?

Юра

Зачем две энтити на одну таблицу

Юра

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

Юра

Будет рассинхрон

Юра

Ваш кейс выглядит как кандидат на CQRS паттерн

Andrei

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

Andrei

а на чтение - да. Никакой нафиг доктрины. это мы уже давно решили)

Andrei

только православный sql с последующим простым меппингом на dto

Andrii

Коллеги, а у вас не было кейса когда нужны две сущности доктрины, основанные на одной и той же таблице?

на Doctrine Discriminator похоже

Юра

Ну так делайте селект в DTO

Юра

Есть же такая возможность в доктрине

Andrei

Ну так делайте селект в DTO

ну это вне агрегата, какие еще DTO в агрегате могут быть?

Юра

Я не знаю если задача выбрать разные представления одной модели, я бы подумал про ДТО и выборку в ДТО

𝕎𝕒𝕣𝕞

Здравствуйте, я делал аутетификацию через jwt токен, прописал пути, и в тесте он кидает исключение Unable to find the controller for path "/api/auth/token/login". The route is wrongly configured.

𝕎𝕒𝕣𝕞

security.yaml