View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5910 | Composr | search | public | 2024-09-05 20:47 | 2024-09-05 20:47 |
| Reporter | PDStig | Assigned To | PDStig | ||
| Priority | high | Severity | minor | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 11.beta2 | ||||
| Summary | 5910: Improve efficiency and accuracy of 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 | ||||
| Tags | Roadmap: v11 | ||||
| Attach Tags | |||||
| Attached Files | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Fixed in Git commit 8a5b2db8ba (https://gitlab.com/composr-foundation/composr/commit/8a5b2db8ba - link will become active once code pushed to GitLab) |
|
|
A hotfix (a TAR of files to upload) has been uploaded to this issue. Only apply this hotfix if you absolutely need it and cannot wait until the next release of Composr (releases are more reliable and strictly tested). As of Composr version 11, the recommended way to apply a hotfix is by following the same steps as an upgrade (https://baseurl/upgrader.php, use the hotfix on the step “Transfer across new/updated files”). The upgrader will automatically skip files belonging to addons you do not have installed or that are newer on disk than in the hotfix. Otherwise, you can manually extract and replace these files (do not replace if your on-disk file is newer than the one in the hotfix). Always take backups of your site or at least files you are replacing before applying a hotfix. Not sure how to extract TAR files to your Windows computer? Try 7-zip (http://www.7-zip.org/). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-05 20:47 | PDStig | Tag Attached: Roadmap: v11 |
