Symfony 5.4, как получить список внешних связей у сущности?

Question

[MikUrrey]

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

$queryBulder  = $repo->createQueryBuilder('a');
$items = $queryBulder->getQuery()->getArrayResult();

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

Comments

[tukreb]

А с чего вы решили что они медленно работают?
Может проблема не в них? А в том как вы их используете?
Может вы используете наследование? Или что-то ещё?
Так или иначе если вам буквально нужно получать на выходе готовые сущности, то есть такая крутая штука как https://www.doctrine-project.org/projects/doctrine...

А ещё есть вариант использовать для чтения БД DBAL доктрины.

[MikUrrey]

tukreb, да, возможно, не получается "правильно приготовить".
Пример:

//$qparametrizer - кастомный класс, забирающий параметры выборки из клиентского запроса
$queryBulder  = $repo->createQueryBuilder('a');
$query      = $queryBulder->getQuery();
$items      = new Paginator($query);
$itemsCount = count($items);
$pagesCount = ceil($itemsCount / $qparametrizer->getLimit());
$data = $items
            ->getQuery()
            ->setFirstResult($qparametrizer->getOffset())
            ->setMaxResults($qparametrizer->getLimit())
            ->getResult()
;
return $this->json([
            'data'      => $data,
]);

Вот такой код, на первый взгляд вроде правильный, вызывает ошибку A circular reference has been detected when serializing the object of class, пока не поставишь кастомный CircularReferenceHandler, тупо отдающий запрошенный объект:

class CircularReferenceHandler
{
    public function __invoke($object) {
        return $object;
    }
}

Мне кажется, на этом этапе уже что-то пошло не так, но так и не нашел что именно.

[tukreb]

MikUrrey, так и где именно тут проблема, по которой вы решили

Из-за медленной работы со связями пришлось отказаться от маппинга

?

Надеюсь вы в курсе, что у симфони есть дебагер? А там внутри есть вкладка Doctrine, где расписаны все вызовы и даже возможность показать Explain query

[MikUrrey]

tukreb, Explain вообще не в ту степь. Проблема не в больших данных или сложных запросах, а в том, что их очень много (>180) и они долго мапятся. Похоже, двунаправленные ассоциации тупо зацикливают нормализатор, и он гоняет одно и то же туда-сюда, пока не уложит сервер.
Раздел performance дает не много информации. Может быть, падая, просто не успевает нормально собрать инфу.

Вот если убрать двунаправленность, ORM отрабатывает за приемлемое время, запросов становится раза в 2,5 меньше, хотя все равно это многовато. Попытаюсь понять, как с этим справлялся Easy Admin, может как-то отключал в рантайме инверсию.

[tukreb]

MikUrrey, ну понятно короче, вы нагородили гору бандлов и пытаетесь из этого сделать феррари :) Это так не работает.
Для симфони полезны только те бандлы - которые упрощают интеграцию сторонних сервисов - типо доктрины, knp пагинатор, работа с ФС и т.д, но и здесь нельзя переусердствовать, например вместо Api-platform лучше использовать ручной swagger
Всё остальное типо EasyAdmin это просто чтобы набросать макет и показать заказчику, а потом переписать всё как нужно. Да и ещё такие бандлы часто бросают на произвол судьбу (возможно конечно не с EasyAdmin, он пока довольно большой) и потом спустя годы, вы обнаружите, что не сможете обновится до последней версии симфони не переписав все бандлы :)
Это ещё не говоря, что бандлы заставляют вас жутко велосипедить пытаясь обойти их ограничения.

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

А для сложный вставок или обновлений можно в доктрине это использовать
https://www.doctrine-project.org/projects/doctrine...

[MikUrrey]

tukreb, я как раз пытаюсь избавиться от EasyAdmin и пишу контроллеры, которые будут его заменять :) Совершенно согласен, не люблю эти труднорасширяемые и слабодокументированные RADости. Но пока что EasyAdmin меня обходит по производительности, а мы, как говорится, "еще ничего не начинали"

[Ivan Bogomolov]

tukreb, не согласен с тем что доктрину нужно велосипедить, там нечего велосипедить. Доктрина это набор отдельных библиотек (адаптеры, утилиты и ORM). Когда вы используйте ORM всё будет работать так как в зададите в настройках маппинга (в том числе поведение как доставать связи, lazy или eager).

Вопрос сам поставлен некорректно.

$queryBulder = $repo->createQueryBuilder('a');
$items = $queryBulder->getQuery()->getArrayResult();

Такой код означает select('a') выбрать ВСЮ сущность (весь объект) со всеми полями и положить её в массив. И так для каждой сущности. Если у вас в базе млн. записей, то будет вытаскиваться млн. объектов.

Тут нет проблемы доктрины, это проблема того кто пишет приложение. Для сравнения вы можете выводить в каталог товаров 20 объектов за раз, и дальне использовать пагинацию. А можете 2000 объектов выводить. Разница будет коллосальная. А в вопросе не указан контекст какие связи необходимо достать. Связи в сущности или МЕТА-информацию о том какими связями обладает сущность.

[MikUrrey]

Ivan Bogomolov, если почитать переписку, можно заметить, что в процесс включен Paginator. И далее, что проблема производительности в итоге найдена в двунаправленных связях. Вопрос поставлен человекопонятно, суть не в терминологии.

[Ivan Bogomolov]

MikUrrey, причём тут двунаправленные связи? Посмотрите для начала как работает knp paginator и лучше сразу им пользуйтесь. У вас paginator берёт query! А затем отдаёт ВСЕ items и вы делайте по ним count($items)!!!! Какой смысл в такой пагинации? Вы даже не предоставили код сущности и разметки маппинга чтобы доказать что двунаправленные связи работают неверно.

[MikUrrey]

Ivan Bogomolov, встроенный Paginator это Iterable объект с перегруженным count, и здесь count это не то же самое, что count($array). В момент вызова count($instance) выполняется обычный для таких случаев SELECT COUNT по заданной таблице с заданными условиями, и ничего лишнего.

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

"У нас в клубе принято джентльменам верить на слово" (с)
Зачем? Я уже разобрался с этой проблемой, убрал inversedBy, что предотвратило зацикливание и сильно сократило количество запросов. И вопрос то был не об этом, да и ответ уже найден. Согласен, сразу уходить в массивы - неоптимально для бизнес-логики, но я пока только начинаю знакомство с Doctrine и пробую разные варианты.

[Ivan Bogomolov]

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

Я уже разобрался с этой проблемой, убрал inversedBy, что предотвратило зацикливание

Это означает что ваш код обращается к свойствам сущности которая хранит ассоциации. По-умолчанию если сущность содержит двунаправленные связи и вы например делайте findAll() то доктрина вам отдаст только поля сущности без связей! Проверьте это и убедитесь что там будет только 1 select запрос. Но если вы во время цикла (например частая ошибка выводят прямо в twig в шаблон в цикле сущности и обращаются к её свойству с inversedBy) , то в таком случае будет вызвыаться ещё 1 select для ассоциативной связи (и там будет зависеть от того какая это связь и будет вызыван либо join либо select).

Поэтому ваша проблема исключительно только в вашем неверном коде Paginatorа или другом месте который не связан с доктриной. Ищите то место где вы обращайтесь к ассоциативой связи и вызывайте одно и свойств ассоциативных связей. Потому что по-умолчанию доктрина будет создавать вам "прокси-сущность" Proxies\__CG__\App\Entity\ВашаСусщностьInversedBy ( https://www.doctrine-project.org/projects/doctrine... )

Вот вам документация о том как работает доктрина https://www.doctrine-project.org/projects/doctrine...

[MikUrrey]

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

Ivan Bogomolov, цепляться за слова и додумывать чужие фразы - контрпродуктивно.

По-умолчанию если сущность содержит двунаправленные связи и вы например делайте findAll() то доктрина вам отдаст только поля сущности без связей! Проверьте это и убедитесь что там будет только 1 select запрос.

И проверил, и убедился, и уже не раз. Теперь проверьте нормализацию сущностей в JSON. Нормализатор потянет все связи и свалится. Скорее всего, именно на инверсиях, т. к. отключая их, получаем нормальный (приемлемый) результат. Но они, к сожалению, нужны для других узлов приложения. Поэтому оставил задачу, пока не появится время погрузиться в настройку нормализации.

[Ivan Bogomolov]

MikUrrey,

вы задали вопрос без приведения кода, фактов, доказательств что доктрина медленно работает со связями. А затем в итоге наконец-то выяснили что это проблема в ВАШЕМ коде и в непонимании работы сериализации.

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

https://symfony.com/doc/current/components/seriali... когда вы что-то конвертируйте в формат, это encoder работает. Нормализация это обратный процесс в терминах symfony.

В вашем случае - нормализация (десериализация) это JSON-> в entity преобразуйте. И сериализация (кодирование (encoding) это entity -> json.

Ещё раз повторю что код symfony тут непричём и код доктрины тут непричём, у вас с таким же успехом может быть любой PPO объект который не относится к библиотечному код, но который будет вызывать circular reference. А в symfony для этого есть документация https://symfony.com/doc/current/components/seriali... и https://symfony.com/doc/current/serializer.html читайте внимательно

Answer 1

[MikUrrey]

public function someAction(
        \Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository $repo, 
        \Symfony\Component\HttpFoundation\Request $request
    ): \Symfony\Component\HttpFoundation\Response
{
        $queryBulder  = $repo->createQueryBuilder('a');
        $em           = $queryBulder->getEntityManager();
        $MetaData     = $em->getClassMetadata($repo->getClassName());
        $associations = $MetaData->getAssociationMappings();
}

Ассоциативным массивом приходит вся необходимая информация, дальше - дело техники.