resultsMap is the best structure for storing and checking results
internally during search, but is kind of messy to iterate over after.
Provide flattened alternatives that make it easier to get the data.
Since we don't really need to remove or reorder, this isn't too painful to manage.
If it's too memory intensive, we can reevaluate.
Search results that have already been claimed/rejected
Inconclusive search results that failed because of an error.
Positive search results that are available to claim/reject.
Search results that have not been claimed/rejected.
Negative search results that are available to claim/reject.
Cancel the search.
Perform the search for each definition.includedSites.
This is incremental. It won't duplicate sites that already have results.
Pause the search
Resume the search
Save/update this search in the database.
Don't call this unless you've made changes! Each call will create a revision and take up space.
Start the search.
Store the resulting account where it needs to go.
Won't overwrite/duplicate accounts whose keys already appear in resultsMap
(noop for those).
This won't return anything unless you pass a searchDefinition prefix!
Load all Searchs from the database into
the Search.cache.
Returns an array of the requested searches. All loaded searches
(including ones not loaded by this request) can be accessed
via Search.cache.
Generated using TypeDoc
Single execution of a
SearchDefinition.