-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collection::makeTree() hits database for each child #231
Comments
I was able to improve the speed of ->toTree() by loading the children relation on the descendants collection before calling toTree(). So instead of Still not as good as it was in 5.1.1, but much better than without loading children (now 2 database queries instead of 1 + (number of descendants)) |
Hello, @ritterg! It seems it's a regression :/ I'm going to fix it and make a new release. |
fixed #231 regression by utilizing relation methods as it was in ClosureTable 5
I can confirm that this (Version 6.0.1) fixes my issue. |
You're welcome! |
I use ->getDescendants()->toTree() to get the whole tree and show it as a hierarchical list of checkboxes.
Up to version 5.1.1 this was one database hit (to get descendants).
select * from
termsinner join
term_closureon
term_closure.
descendant=
terms.
idwhere
term_closure.
ancestor= 1 and
term_closure.
depth> 0
In version 6 it is now one database hit (to get descendants, same as above) and one database hit for each child
select * from
termswhere
terms.
parent_id= 2 and
terms.
parent_idis not null
This makes building a larger tree very slow.
The problem seems to be on line 174 of Collection.php:
$result[$parentId]->children->add($item);
which used to be (in 5.1.1, Collection.php line 80)
$result[$parentId]->appendRelation($item->getChildrenRelationIndex(), $item);
Is there a way to get the tree without all these database hits?
The text was updated successfully, but these errors were encountered: