Size: a a a

2020 November 09

IM

Ilya Medzhidov 🖋 in symfony
Roman Kutenko
Он в 4.4 деприкейтед, в 5 уже наверно выпелен!

Вот мне бы так ответили, я пару недель пытался понять почему такая фигня у меня была после обновления с 4.2 на 4.4
Как в итоге нашёл ответ? Changelog перекопал?)
источник

RK

Roman Kutenko in symfony
Ilya Medzhidov 🖋
Как в итоге нашёл ответ? Changelog перекопал?)
брекпоинтами обвешали приложение и искали почему $debug всегда false, докапались до класса Debug и решили его подключить в эндпоинте )
источник

AN

Alexander Nazarov in symfony
Павел Г.
Привествую. Есть "крутое" архитектурное решение где результат api - это json который включаетв  себя кучу сущностей разного вложения. Все это работает через ОРМ + Lazy load, что дает результат в 150 запросов с супер гидрацией всех сущностей...
В какую адекватную сторону копать чтобы это оптимизировать и не захлебнуться?  
Пока что вижу только eager load +particial + ArrayResult.
Но как я понимаю, по хорошему надо делать вывод не через EM а через Connection и чистые запросы к базе. Но вложенность мама не горюй, это делать штук 10 простых запросов а потом их результаты собирать в один большой массив?
так наверное ни кто не сможет ответить. Это надо больше погружаться в предметную область. Понимать реализацию и ее проблемы.
источник

RK

Roman Kutenko in symfony
Changelog это первое что читал перед обновлением
источник

IM

Ilya Medzhidov 🖋 in symfony
Roman Kutenko
брекпоинтами обвешали приложение и искали почему $debug всегда false, докапались до класса Debug и решили его подключить в эндпоинте )
Жесть)
источник

ПГ

Павел Г. in symfony
Alexander Nazarov
так наверное ни кто не сможет ответить. Это надо больше погружаться в предметную область. Понимать реализацию и ее проблемы.
Да тут особо предметная область не при чем. Разработали API с огромной вложенностью сущностей.  Как вот такое адекватно вывести в json?  Речь же про вывод, а не про ввод. Промапить данные из БД но сразу много и с связями на json
источник

AN

Alexander Nazarov in symfony
Павел Г.
Да тут особо предметная область не при чем. Разработали API с огромной вложенностью сущностей.  Как вот такое адекватно вывести в json?  Речь же про вывод, а не про ввод. Промапить данные из БД но сразу много и с связями на json
Ну как сказать. На сколько правильно для этого была выбрана структура хранения, на сколько правильно выбрали БД. Действительно ли в ответах всегда нужна такая большая вложенность. Можно ли разбить ее. Почему не посмотреть в сторону GraphQL и т.п.
источник

AN

Alexander Nazarov in symfony
Если вы прям так в лоб спрашиваете, то конечно ваши запросы по отдельности будут выполняться быстрее, чем через ORM со всеми прицепами.
источник

AS

Anton Syuskov in symfony
А почему не написать запрос в репозитории? На всю необходимую пачку данных?
источник

ПГ

Павел Г. in symfony
Alexander Nazarov
Ну как сказать. На сколько правильно для этого была выбрана структура хранения, на сколько правильно выбрали БД. Действительно ли в ответах всегда нужна такая большая вложенность. Можно ли разбить ее. Почему не посмотреть в сторону GraphQL и т.п.
Ну вопрос не как архитектуру изменить, а как подстроиться под текущее решение
источник

ПГ

Павел Г. in symfony
Anton Syuskov
А почему не написать запрос в репозитории? На всю необходимую пачку данных?
Ну я написал, что один из вариантов это eager load запрос с маппингом на массив а не сущности
источник

ПГ

Павел Г. in symfony
Но все таки вроде как лучше через connection, но как лучше сделать и стоит ли вообще
источник

AN

Alexander Nazarov in symfony
Павел Г.
Ну вопрос не как архитектуру изменить, а как подстроиться под текущее решение
Ну вы сами на него ответили сразу же. Чистые запросы на connection как вариант решения. Почему нет?
источник

ПГ

Павел Г. in symfony
Alexander Nazarov
Ну вы сами на него ответили сразу же. Чистые запросы на connection как вариант решения. Почему нет?
Ну типо 10 запросов а потом строить огромный массив? Это норм путь?
источник

AS

Anton Syuskov in symfony
Павел Г.
Ну я написал, что один из вариантов это eager load запрос с маппингом на массив а не сущности
Я имел в виду не забрать отдельную Entity, которая потащит за собой все остальное. А получить сырые данные и промапать в какое-нибудь dto
источник

ПГ

Павел Г. in symfony
Я просто боюсь нпаисать бОльшее гавно чем есть, не предоставив профита
источник

AN

Alexander Nazarov in symfony
Павел Г.
Ну типо 10 запросов а потом строить огромный массив? Это норм путь?
Мне кажется тут не может быть такого понятия как норм путь. У вас есть задача которую вы решаете. Красивый вариант через ОРМ вас не устраивает, остаются некрасивые.
источник

ПГ

Павел Г. in symfony
Anton Syuskov
Я имел в виду не забрать отдельную Entity, которая потащит за собой все остальное. А получить сырые данные и промапать в какое-нибудь dto
ВОт весь вопрос "Как это лучше сделать". Там куча сущностей. Получить серые данные через 10 запросов? Или есть интересные пути по куче join а потом как то размапить эту бедеберду на норм структуру?
источник

MM

Maksim Masiukevich in symfony
Доктрина для чтения для рендера не используется.
Вот ответ на то, как сие оптимизировать
источник

MM

Maksim Masiukevich in symfony
Ну или любая другая орм, пофигу
источник