The Query Elevation Component lets you configure the top results for a given query regardless of the normal Lucene scoring.
This is sometimes called "sponsored search", "editorial boosting", or "best bets." This component matches the user query text to a configured map of top results. The text can be any string or non-string IDs, as long as it’s indexed. Although this component will work with any QueryParser, it makes the most sense to use with DisMax or eDisMax.
The Query Elevation Component also supports distributed searching.
You can configure the Query Elevation Component in the solrconfig.xml file. Search components like QueryElevationComponent may be added to any request handler; a dedicated request handler is used here for brevity.
Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter.
Path to the file that defines query elevation. This file must exist in <instanceDir>/conf/<config-file> or <dataDir>/<config-file>. If the file exists in the conf/ directory it will be loaded once at startup. If it exists in the data/ directory, it will be reloaded for each IndexReader.
By default, this component respects the requested sort parameter: if the request asks to sort by date, it will order the results by date. If forceElevation=true (the default), results will first return the boosted docs, then order by date.
In this example, the query "foo bar" would first return documents 1, 2 and 3, then whatever normally appears for the same query. For the query "ipod", it would first return "MA147LL/A", and would make sure that "IW-02" is not in the result set.
If documents to be elevated are not defined in the elevate.xml file, they should be passed in at query time with the elevateIds parameter.
When the elevation component is in use, the pre-configured list of elevations for a query can be overridden at request time to use the unique keys specified in these request parameters.
If either one of these parameters is specified at request time, the the entire elevation configuration for the query is ignored.
Query elevation respects the standard filter query (fq) parameter. That is, if the query contains the fq parameter, all results will be within that filter even if elevate.xml adds other documents to the result set.