#5910 - Improve efficiency and accuracy of search
-
By PDStig
- Added
- 3 views
| Identifier | #5910 |
|---|---|
| Issue type | Minor issue (breaks specific functionality) |
| Title | Improve efficiency and accuracy of search |
| Status | Completed |
| Tags |
Roadmap: v11 (custom) |
| Handling member | PDStig |
| Version | 11 beta2 |
| Addon | search |
| Description | The search feature of Composr v11 was very inaccurate. The start/max parameters were passed to each search hook, but this was the wrong way to go about it for several reasons: 1) Hooks do not have good awareness of how many results previous hooks already returned. 2) Hooks have even less awareness where their starting position should be based on a combination of $start and what other hooks prior have returned. The patch in this issue changes search behaviour in the following ways: 1) We now always pass 0 as start and general_safety_listing_limit as max to each search hook regardless of the start and max positions we want 2) Search results are cached for 15 minutes. All parameters except pagination and sorting, plus a random identifier added to all pagination links, is used as the cache identifier. Additionally, the cache is against the member to prevent content leaks. 3) When a cache is available (usually via pagination), search will load up the cached results instead of re-calculating everything. If no cache is available or a search ID was not provided, results are re-calculated and then cached. 4) We do not put the hook objects in the results anymore because this will significantly increase memory and cache size. Instead, build_search_results_interface will grab the hook object when it is needed to render the result. By doing the above, we have fixed the following issues: 1) While initial search may be a tad slower (I did not notice much of an issue... each hook is given 10 seconds but the overall search for "points" only took about 3, for example), pagination is much faster because we are not re-calculating searches every time. 2) Result numbers do not keep changing on each page (unless the cache gets broken). 3) Some search hooks were never running given the previous behaviour, so we are actually searching in every hook we need to now. This behaviour does not apply to catalogue entry searching via tickets. Therefore, we must keep start and max parameters for search hooks for custom searches like that as an example. This patch also fixes #5598 |
| Steps to reproduce | |
| Funded? | No |
| Commits |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments