Feature(s) impacted
Advanced Search
Observed behavior
We have a huge table related to user sessions. We are trying to search for a ID which is PK in the table. Forest is generating huge monster query with 12 left joins in the backend. We have tried restrict the search fields and having indexes in table as mentioned in the below article but no use https://docs.forestadmin.com/documentation/reference-guide/performance
Expected behavior
Is there any way that we can restrict joins of forest in the collections page. And it can fetch or load the all data when the user clicks on a particular record (some thing like lazy loading). Is there any way do this in this way?
Failure Logs
Context
- Project name: …
- Team name: …
- Environment name: …
- Agent technology: (nodejs, php, rails, python) nodejs
- Agent (forest package) name & version: …
- Database type: MySQL
- Recent changes made on your end if any: …
Hello @Sudheer_K and welcome to the community!
Could you try to reduce the number of columns displayed in the collection page ? Each relationship would be queried when listing your table.
@dogan.ay thanks for responding.
I can reduce the number of columns but i need all the data in individual record summary page. How can i differentiate the both. As of now i can see forest using same server file to display the records at collection level and individual record…
You can hide the field in the collection view only by editing the layout. Each team has its own layout so you will have to do so for each team that needs the perf improvements.
I tried, it didn’t solved my problem.
My problem is with Advanced search. When i enter some text for search forest generating a big query with 12 joins and getting time out error. How can i remove unwanted joins ?
I have been looking for a solution but sadly it seems that there will be no easy fix.
You could try to experiment with the searchFields property, this should help to reduce the size of the generated request but it won’t remove the join for every item either. You can define properties for the extended search as follows: 'user.name'
.
Another workaround would be to override the list route for this collection and implement your own logic.
The optimal solution would be to migrate to agent v2 which had performance resolution as one of its main goal, but I understand that this might not answer your short term needs.