This PR solves a problem generating the cache for the prospect reports. The process of cache generation was stuck on a percentage less than 100%.
Before
While running the "Refresh All Pivot Reports", the action get stopped, because of a timeout error in one of the Ajax request performed:
After
The action finishes without errors:
Technical Details
The timeout observed is in one of the requests to the Prospect API (with Js library), for getting a set of results in order to create the report cache.
For solving this, without having to think about query optimization, we can use the constant defined on CRM_PivotData_AbstractData class named ROWS_API_LIMIT. This indicates the number of results to be queried on every call to CiviCRM API, for each entity. A lower number could speedup the query time, and the result will be the same, since the calls are performed one after the other until there is no more results.
We can override that value for the Prospect entity, in CRM_PivotData_DataProspect class, which is the one with performance problems. The same was done before with the Activity related class.
Using 500 instead of 1000 probed to solve the problem.
Note: The query could be working slowly now since we have recently added an extra condition to the where clause on Prospects. Nevertheless, in the environments where this fail (which are not production environments) the query was also timing out before this change.
Overview
This PR solves a problem generating the cache for the prospect reports. The process of cache generation was stuck on a percentage less than 100%.
Before
While running the "Refresh All Pivot Reports", the action get stopped, because of a timeout error in one of the Ajax request performed:
After
The action finishes without errors:
Technical Details
The timeout observed is in one of the requests to the Prospect API (with Js library), for getting a set of results in order to create the report cache. For solving this, without having to think about query optimization, we can use the constant defined on
CRM_PivotData_AbstractDataclass namedROWS_API_LIMIT. This indicates the number of results to be queried on every call to CiviCRM API, for each entity. A lower number could speedup the query time, and the result will be the same, since the calls are performed one after the other until there is no more results. We can override that value for the Prospect entity, inCRM_PivotData_DataProspectclass, which is the one with performance problems. The same was done before with the Activity related class. Using 500 instead of 1000 probed to solve the problem. Note: The query could be working slowly now since we have recently added an extra condition to the where clause on Prospects. Nevertheless, in the environments where this fail (which are not production environments) the query was also timing out before this change.