Solr:Performing queries and handling results

The anatomy of a Solr request

Request handlers

Request handlers are the entry points for essentially all requests to Solr. Their job is to receive a request, perform some function, and return a response to the client.

 

 

http://localhost:8983/solr/collection1/select/
http://localhost:8983/solr/collection1/update/
http://localhost:8983/solr/collection1/replication/
http://localhost:8983/solr/collection1/private/search/

 

Search components

Search components are configurable processing steps that occur within the lifetime of a search handler. Search components allow a search handler to chain together reusable pieces of functionality that can be executed with a single search request.Search components are configured in solrconfig.xml

 

 

 

Out of all the search components in the search handler, the query component is the most important, as it’s responsible for initially running the query and making the results available in the response (and for other search components to make use of afterward). The query component makes use of a query parser to interpret the incoming query from the request to the search handler.

 

Query parsers

Query parsers are used to interpret a search syntax into a Lucene query for finding a desired set of documents.

 ------------------------------------------------------------------------------------------------------------------------------------

Working with query parsers

When executing a search, QueryComponent handles the primary user query (the q parameter) by passing its value along to a query parser. As mentioned in  lathest section, LuceneQParserPlugin is the default query parser in Solr.

 

Specifying a query parser

The default query parser type to be used for the QueryComponent can be modified using the defType parameter on the search request:

/select?defType=edismax&q=...
/select?defType=term&q=...

/select?q={!edismax}hello world
/select?q={!term}hello
/select?q={!edismax}hello world OR {!lucene}title:"my title"

 

Local params

Local params provide the ability to localize request parameters to a specific context.Typically you will pass request parameters to Solr on the URL, but sometimes you may only want some parameters to be applied to certain parts of the query. Within the context of a query, local params allow you to pass request parameters only to the specific query parser that you want to consider them, as opposed to making all request parameters global.

LOCAL PARAMS SYNTAX
{!param1=value1 param2=value2 ... paramN=valueN}

 

/select?q=hello world&defType=edismax&qf=title^10 text&q.op=AND
||
/select?q={!defType=edismax qf="title^10 text" q.op=AND}hello world

The real difference between these two queries is that, in the first example, all of the request parameters are global.

PARAMETER DEREFERENCING
/select?q={!edismax v=$userQuery}&userQuery="hello world"

----------------------------------------------------------------------------------------------------------------------------------

Queries and filters

A search in Solr is composed of two main operations—finding the documents that match the request parameters and ordering those documents so that only the top matches need to be returned.

The fq and q parameters

what is the difference between the q and fq parameters? fq serves a single purpose: to limit your results to a set of matching documents.The q parameter, in contrast, serves two purposes:

1. To limit your results to a set of matching documents
2. To supply the relevancy algorithm with a list of terms to be used for relevancy scoring

 

 

The default query parser (Lucene query parser)

The default query parser in Solr is confusingly called the Lucene query parser (implemented in the class LuceneQParserPlugin)

1. The Lucene query parser includes an expressive syntax for creating arbitrarily complex Boolean queries, but it has a few major drawbacks that make it less than ideal for handling user queries. The most problematic of these is that the Lucene query parser expects a strict syntax that, if broken, will throw an exception. Because it’s often unreasonable to expect your users to understand and always enter perfect Lucene query syntax when typing in their keywords, this relegates the Lucene query parser to not being user-friendly enough for many applications.
2. An additional drawback of the Lucene query parser is its inability to search across multiple fields by default.

-----------------------------------------------------------------------------------------------------------------------------------

Handling user queries (eDisMax query parser)

The eDisMax query parser is essentially a combination of two other query parsers, the Lucene query parser and Disjunction Max (DisMax) query parser.