Комментарии 11
Оказалось, что для генерации данных некоторые модели (в глубине давно написанных сервисов) требовали связанные one-to-many объекты. Объект нужен был один, но для доступа к нему поднимался весь ArrayCollection из сотен объектов.
Я так понимаю, что помимо медленной гидрации (проблема со стороны Doctrine) это еще и ошибка в логике работы проекта, верно? Вместо того, чтобы выбирать только необходимые связанные объекты DQL запросом, выбирались все записи. Или по-другому было нельзя?
Да, разумеется, это была ошибка логики бизнес объектов. Я пытался именно это и сказать, но не получилось это сделать ясно, видимо.
Но не то, что выбирались все объекты, а не выбирались вообще ни одного. И доктрин из-за этого уже сам вытаскивал их всех.
Т.е. было обращение, допуcтим,
$record = $entity->getRecordByKey($key);
внутри которой было
public funtion getRecordByKey($key) {return $this->records[$key]; }
Если нужный record к моменту вызова getRecordByKey не был готов, но доктрин лез и выбирал все связанные records из базы.
И это правильно. К Доктрин претензий нет, и отработал он отлично. Но при этом такую ошибку допутить легко (ну не знаю, обращение к null-объекту у всех же случаяются периодически), а отладить сложно. Стандартный профайлер не помогает никак. А мой бандл «проявляет» ошибку, если можно так сказать.
Но не то, что выбирались все объекты, а не выбирались вообще ни одного. И доктрин из-за этого уже сам вытаскивал их всех.
Т.е. было обращение, допуcтим,
$record = $entity->getRecordByKey($key);
внутри которой было
public funtion getRecordByKey($key) {return $this->records[$key]; }
Если нужный record к моменту вызова getRecordByKey не был готов, но доктрин лез и выбирал все связанные records из базы.
И это правильно. К Доктрин претензий нет, и отработал он отлично. Но при этом такую ошибку допутить легко (ну не знаю, обращение к null-объекту у всех же случаяются периодически), а отладить сложно. Стандартный профайлер не помогает никак. А мой бандл «проявляет» ошибку, если можно так сказать.
Понятно, спасибо.
Но ведь у коллекций (а у вас там должен быть ArrayCollection/PersistedCollection) есть и специальные фильтры, и методы для получения элементов по нужному индексу, срезки элементов, их подсчета. И EXTRA_LAZY режим.
Можно включить его и тогда получение по индексу не будет вызывать гидрации всех связанных объектов. То есть, да, тут неверное использование ORM.
А профайлер гидрации — это полезно, да.
Можно включить его и тогда получение по индексу не будет вызывать гидрации всех связанных объектов. То есть, да, тут неверное использование ORM.
А профайлер гидрации — это полезно, да.
Думаю в виде отдельного бандла мало кто будет использовать ваше творение. ПР в доктрину был бы куда полезнее
Да, я хочу попробовать это сделать.
Но, во-первых, не факт, что отцы-основатели посчитают это достойной мастера фичей.
Во-вторых, это требует поэтапного внедрения — сначала в doctrine/orm, и, после того, как это уйдет в стабильный мастер, уже в doctrine/doctrine-bundle. И это точно произойдет небыстро.
А бандл уже готов и уже работает.
Но, во-первых, не факт, что отцы-основатели посчитают это достойной мастера фичей.
Во-вторых, это требует поэтапного внедрения — сначала в doctrine/orm, и, после того, как это уйдет в стабильный мастер, уже в doctrine/doctrine-bundle. И это точно произойдет небыстро.
А бандл уже готов и уже работает.
А в packagist.org не хотите свой бандл добавить?
Он уже там.
Я не стал это упоминать, но в инструкция по установке в гитхабе использует composer, т.е. это значит что бандл уже в пакаджисте.
Я не стал это упоминать, но в инструкция по установке в гитхабе использует composer, т.е. это значит что бандл уже в пакаджисте.
Респектище вам за бандл!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Неочевидные проблемы с быстродействием в Doctrine, связанные с гидрацией объектов