SOLR features three: queryelevation (edit result sort)

Ideally, the search engine only returns documents related to user queries. In a real-world query, editors (not finding a more appropriate expression) often need to specify specific documents in the search results in a specific location. There are many reasons for doing so. Perhaps the "sticky" document is the best query result. It may also be that the company wants customers to find higher-margin products from similar choices. It may also be paid by third parties to improve the ranking of certain query terms. Whatever the reason, for general queries, it is often difficult (or even impossible) to rank specific documents in a particular location, depending on the degree of relevance. And even if a search engine can do this for a query, it is likely to break the other 50 queries in the process. As a result, real-world searches have a basic rule: a user input query does not mean that you must search the index and rate the document. I know that people who build search engines say it's a bit strange, but it's true. You can cache a normal query, or just look for results (SOLR can do it), or "hard-coded" results based on one of the above reasons.

SOLR uses a mysterious name SearchComponent (i.e. QueryElevationComponent ) to achieve a simple ranking. To configure it in the sample application, I declare it as shown in Listing 14:

Listing 14. Declares a QueryElevationComponent

<searchcomponent name= "Elevator"  class= "Org.apache.solr.handler.component.QueryElevationComponent  " >     <!--pick a fieldtype to analyze queries--     <str name= "Queryfieldtype" >string</str>     <str name= "Config-file" >elevate.xml</str>   </searchComponent>

queryFieldTypeproperty specifies how the incoming query matches the query to be promoted. For simplicity, it string FieldType means that the query must be a string that is exactly matched because string FieldType no analysis is performed on it. config-fileproperty specifies the file that contains the query and associated results. It is stored in a separate file so that it can be edited externally. The file must be in the SOLR configuration directory or in the SOLR data directory. If it is not in the data directory, it will be loaded when SOLR needs to reload the index.

The sample application stores Elevate.xml in the configuration directory. Inside it, I added an entry for query "Charlotte", along with 3 other entries, as shown in Listing 15:

Listing 15. Sample Elevate.xml Configuration

<query text= "SOLR" >  <doc  id= "http://lucene.grantingersoll.com/2008/06/21/ solr-spell-checking-addition/"/>  <doc <!--line break are for   formatting purposes--  id=" http ://lucene.grantingersoll.com/2008/10/01/\       charlotte-jug-%c2%bb-oct-15th-6pm-search-and-text-analysis/"          />  <doc  id= "http://lucene.grantingersoll.com/2008/08/27/solr-logo-contest/" exclude= "true"/ >  </query>

Listing 15 indicates that the first link should appear above the second link, and the third link must be excluded from the result. The results are then sorted in the normal order. To see the normal results (when this component is included, the promotion is turned on by default), run the following query:

Http://localhost:8983/solr/rss/select/?q=Solr&version=2.2&start=0&rows=10&indent=on   & Fl=link&enableelevation=false

To see the results when the promotion is open, try:

Http://localhost:8983/solr/rss/select/?q=Solr&version=2.2&start=0&rows=10&indent=on   & Fl=link&enableelevation=true

You should see an inserted boost output.

This is the edit sort. Now you can easily change query results for search without compromising the quality of other results.

SOLR features three: queryelevation (edit result sort)