When restoring content, this adds it to a queue for indexing. If the
restored content was then deleted before the indexing takes place,
this caused an exception in the scheduled task.
This change makes it continue safely past missing contexts.
Implements a mechanism by which search engines can provide different
result orderings, and implements a 'by location' ordering within the
Solr search engine (available whenever the user starts their search
from within a course or activity).
Adds group support to the core search API and the Solr search engine.
This allows for:
* User searching by group (in the API only, no interface yet)
* Automatically restrict search results by group (in some cases like
separate-groups forums)
Adds a new 'Gradual reindex' link to the search areas page for each
area. When clicked, this takes you to a confirm prompt, and then
adds each context from that search area to the indexing queue.
The search areas page now displays the 'Additional indexing queue'
(if it is non-empty). The table shows the first 10 items in the
queue, and it also indicates the total number in case there are
more. (I don't think people really need to see the entire
contents of it, so I didn't implement paging.)
Adds indexpriority field to the database table which holds a queue of
indexing requests. This allows for potentially large area reindexes
to have a lower priority, so as not to halt the special indexes that
run after a course restore.
Without this change its possible that the unit tests will fail at any time.
Before this change the indexing time is measured by real-time, not fake time,
making all index timings 0.
This happens as PHP offers no guarantee around the sort-order of an array for
any given two members that equate as equal. It just happens to pass for the
current array of search areas in vanilla Moodle.
New API \core_search\manager::request_index($context, $areaid = '')
adds the given context to a list which is intended to be indexed
later by the scheduled task.
New function \core_search\manager::is_indexing_enabled(), analagous
to existing is_global_search_enabled().
This replaces existing duplicated code, ready for more use in
following commits.
Allow Global Search 3rd party engines to be much faster by supporting batch processing.
Refactor the iterator loop for the documents to add to the search index into its own method.
Move this new method from the manger class to the base engine class.
The move to the base engine class will allow search engine plugins to override this and determine
how they implment it. It will not break the existing interface contract with existing plugins.
Finally, add an elasped time indication to the trace output.
Also removing is_server_ready call from execute_query as in production
workflows search is done through \core_search\manager::search and
\core_search\manager::instance already checks is_server_ready. In
testing environment setUp functions should check that the server is
ready before performing other actions.
Ensures that Solr will return available results, even if there are many
misses when using check_access(), by asking Solr for more results if the
counter says there should be more.
Improves performance by ending processing as soon as the requested page
of results is processed. Remaining number of pages is an "estimate"
based on the total result count from Solr and how many items we have
rejected up to this point.
Introducing both APIs in moodle along with:
- search_box widget to add a tiny search box
- admin settings with setup steps helper
- cache for search results
- template for a search result
- php unit stuff
Many thanks to Tomasz Muras, Prateek Sachan and Daniel Neis for their contributions, for starting this development
and for pushing for it to be completed. Also thanks to other contributors: Jonathan Harker and eugeneventer.
David Monllao