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 am using this lib to improve performance of my app by reducing number of DB queries.
It wold be great to split features of collector to two methods:
collect - current implementation - used to collect associations
fetch/load - allows to fetch associations to reduce number of queries. (returns void)
Why to split: collect, because it has to return results need to accept 'single path' like `car->engine->parts) where each of elements is child of previous one.
fetch in opposite side should allow to handle 'tree' path:
$paths = [
'engine' => ['parts'],
'fuel'
];
As a result it will fetch:
engine of car (and used parts)
fuel type of car
I think that there will not be any way to optimize it (at least I dont know how) , so under the hood it may just do
This is an idea that I also had in mind, but just didn't get to it yet - so I'm all for it. However you should keep in mind that it will only skip collecting of the leaf entities, i.e. the last association in each path. The preceding entities need to be collected to fetch the next level. Hopefully I will get to implementing it in the near future.
I am using this lib to improve performance of my app by reducing number of DB queries.
It wold be great to split features of collector to two methods:
Why to split:
collect
, because it has to return results need to accept 'single path' like `car->engine->parts) where each of elements is child of previous one.fetch
in opposite side should allow to handle 'tree' path:As a result it will fetch:
I think that there will not be any way to optimize it (at least I dont know how) , so under the hood it may just do
Do you think it may be a 'common/practice' use case, to be worth to add to library?
Classes used in example
The text was updated successfully, but these errors were encountered: