...
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.
...
For the courseware index example it matters whether this is on in the CMS settings, not the LMS settings, since indexing is tied into signals that happen during course publish.
edx-search Uses by Index
index name | what is it? | indexer | searcher |
|---|---|---|---|
courseware_content | course content | CoursewareSearchIndexer in platform/cms | /search and perform_search in edx-search |
library_index | library content, similar to courseware_content | LibrarySearchIndexer in platform/cms | LibraryToolsService in platform/xmodule |
course_info | course about info, maybe this object | CourseAboutSearchIndexer in platform/cms | course_discovery_search and its endpoint in edx-search |
content_library_index | library metadata | ContentLibraryIndexer in platform/core/content libraries app | the same indexer, via its parent class get function which is exposed via an API |
content_library_block_index | library content | LibraryBlockIndexer in platform/core/content libraries app | the same indexer, via its parent class get function which is exposed via an API |
course_team_index | team info but not members | CourseTeamIndexer in platform/lms teams app | Team list view in the same app |
Course Content for Indices
The indexers which run over course content, CoursewareSearchIndexer and LibrarySearchIndexer, get the bulk of that content by calling index_dictionary provided by the xblock IndexInfoMixin. This allows xblocks to be completely flexible in their indexed content, at the price of scattering information about what that content is across all xblocks.
Best Indexer/Searcher Practices
...
Doing their own searching means that these indexes can’t use the extension points, but it also means they don’t have to because the filters and results are customized to their particular use case.
One twist on Two problems wth calling this format a best practice: it’s
This search is not enabled by default or on edx.org, so unless it has other users it could be completely broken and we wouldn’t know.
The distributed nature of xblock content makes a unified schema extremely difficult, so this might not be applicable for course content search.
So Many Settings
There are minor settings for specific search tweaks I’m going to skip to keep these tables compact.
...
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.
...