...
LMSSearchResultsProcessor: since it has the user, it restricts access to blocks the user can see, and provides proper links. Not currently in use, so this may not work. For course staff users, it short circuits access checks which should help performance. For other users, it is based on a very standard
get_course_blockscall, which could well be the only way to reliably guarantee that the restrictions on search match the restrictions on content in general. No matter how many matches are returned from a course only one such call will be made, but no matter how few matches are returned the call will always get all available blocks, so there might be room for optimization in the low match case.
The Search Initializer works at a different level. It is not attached to the API functions but is attached to the do_search course search view. It “sets up the environment” which doesn’t help us understand it much.
...
Setting | What is it? | Set to |
|---|---|---|
SEARCH_ENGINE | which engine class to use | search.elastic.ElasticSearchEngine via cms & lms production.py |
COURSEWARE_CONTENT_INDEX_NAME, COURSEWARE_INFO_INDEX_NAME | index names | left at code default, could not be changed since the indexer does not know the setting |
ELASTIC_SEARCH_*, ELASTIC_FIELD_MAPPINGS | various elasticsearch specific settings | generally set to use version 7 values |
SEARCH_RESULT_PROCESSOR, SEARCH_INITIALIZER, SEARCH_FILTER_GENERATOR | expansion points, see above | set to courseware search, LMS specific values in common.py |
Special note for SEARCH_ENGINE
...
This setting is in lms and cms production.py, but it is only actually set if a selection of the other search settings are True. THAT SELECTION IS DIFFERENT FOR LMS AND CMS.
...