You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've kind of rewriten querying of toOne relations. It is more data and query-count effective.
How?
Let's demonstrate it on CmsUser and CmsAddress from tests models. Let's solve behaviour for toOne relations that are not mentioned in the query.
SELECT u FROM CmsUser u
lazy mapped by side
Already implemented, result is that CmsAddress would be proxy.
lazy inverse side
CmsUser has CmsAddress relation that is mapped and owned by CmsAddress entity.
What has to happen? The identifier of CmsAddress cannot be loaded from users table nad has to be added automatic join for the table. Because it's lazy it will be hydrated as proxy, becase that is exactly what I've asked for.
If it would have been eagerly loaded, It would create 1N queries problem that I'm trying to avoid with this. I have the relation as lazy, if I knew I would have needed it and wanned to optimized, I'd join it, but I didn't.
Result is therefore CmsUser entity CmsAddress proxy
eager - both inverse and mapped by sides
The appropriate query component is generated with autojoin and auto selecting of the entity.
If it is self-referencing, the auto join is not generated becase it would cause infinite recursion.
I would have to go and list all the entities as partials to save performace creating such monsters as this
$builder = $repository->createQueryBuilder("o")
->leftJoin("o.voucher", "vu")->addSelect("partial vu.{id}")
->leftJoin("o.address", "a")->addSelect("a")
->leftJoin("o.restaurant", "r")->addSelect("partial r.{id, name}")
->leftJoin("o.payment", "p")->addSelect("partial p.{id}")
->leftJoin("o.rating", "rat")->addSelect("partial rat.{id}")
->leftJoin("r.settings", "rs")->addSelect("partial rs.{id}")
->leftJoin("r.address", "ra")->addSelect("ra")
->leftJoin("r.position", "rp")->addSelect("partial rp.{id}");
# plus about five more just to make save performace
We all know that hydrating a large result set is a bottleneck and if I say the relation is lazy and I'm not joining it I _really don't want it to be joined with all it's data_!
Now imagine I just want to select few orders and render some data on the page.. I have tens of queries like this just because I have to. This is wrong that the ORM is tripping my feet like this.
What now?
I know I have to solve theese:
more refactoring?
more tests
what to do with issue tests that now have changed behaviour?
Any suggestions?
The text was updated successfully, but these errors were encountered:
Jira issue originally created by user @doctrinebot:
This issue is created automatically through a Github pull request on behalf of fprochazka:
Url: #970
Message:
What is this?
I've kind of rewriten querying of toOne relations. It is more data and query-count effective.
How?
Let's demonstrate it on
CmsUser
andCmsAddress
from tests models. Let's solve behaviour for toOne relations that are not mentioned in the query.lazy mapped by side
Already implemented, result is that CmsAddress would be proxy.
lazy inverse side
CmsUser
hasCmsAddress
relation that is mapped and owned byCmsAddress
entity.What has to happen? The identifier of
CmsAddress
cannot be loaded from users table nad has to be added automatic join for the table. Because it's lazy it will be hydrated as proxy, becase that is exactly what I've asked for.If it would have been eagerly loaded, It would create 1N queries problem that I'm trying to avoid with this. I have the relation as lazy, if I knew I would have needed it and wanned to optimized, I'd join it, but I didn't.
Result is therefore
CmsUser
entityCmsAddress
proxyeager - both inverse and mapped by sides
The appropriate query component is generated with autojoin and auto selecting of the entity.
If it is self-referencing, the auto join is not generated becase it would cause infinite recursion.
Why?
I've given this a lot of thought and tested it on our not-so-small application. We have unfortunately lot of entitiy relations that are mapped on the inverse side than we need to select, which is effectively killing performace [DDC-357](http://www.doctrine-project.org/jira/browse/[DDC-357]%28http://www.doctrine-project.org/jira/browse/DDC-357%29)
I would have to go and list all the entities as partials to save performace creating such monsters as this
We all know that hydrating a large result set is a bottleneck and if I say the relation is lazy and I'm not joining it I _really don't want it to be joined with all it's data_!
Now imagine I just want to select few orders and render some data on the page.. I have tens of queries like this just because I have to. This is wrong that the ORM is tripping my feet like this.
What now?
I know I have to solve theese:
Any suggestions?
The text was updated successfully, but these errors were encountered: