We saw request handlers in the previous chapter. There, we defined a request handler as a pluggable component that handles incoming requests. In that chapter, we were referring to update requests, that is, requests containing index update commands.
Here, we will focus our attention on SearchHandler
, a special front controller used to handle incoming search requests. The SearchHandler
class, although it could be seen as the supertype layer of all search handlers, is not abstract and it defines a standard search behavior.
StandardRequestHandler
is an empty subclass of SearchHanlder
, so at the time of writing this book, using one of them is basically the same. Request handlers are declared in the solrconfig.xml
file, and they define search endpoints. Each instance is associated with a given name prefixed by a slash (the name must be unique), an implementation class, and a set of configuration parameters:
<requestHandler name="/mySeacher" class="solr.SearchHandler"> (configuration) </requestHandler>
With the sample Solr instance running, the preceding handler will answer to one of these URIs:
http://localhost:8983/solr/example/query
http://localhost:8983/solr/example/facets
http://localhost:8983/solr/example/jazz
Configuring a SearchHandler
instance means defining configuration parameters and (optionally) search components that will participate in the query execution chain.
Most of the time, unless you have a specific need, the search components that drive the logic of the search execution can be omitted because the following list will be automatically injected:
Code |
Component |
---|---|
|
QueryComponent |
|
FacetComponent |
|
MoreLikeThisComponent |
|
HighlightComponent |
|
StatsComponent |
|
DebugComponent |
Only the "query" component is enabled; the others need to be explicitly activated.
If the default chain is not what you need, it is possible to define a custom chain in the following way:
<arr name="components"> <str>query</str> <str>facet</str> …other components follow </arr>
This will completely replace the default chain. It is also possible to leave the default chain as it is and have additional prepended or appended components:
<arr name="first-components"> <str>my_custom_component</str> …other components follow </arr> <arr name="last-components"> <str>another_custom_component</str> …other components follow </arr>
So, in general, the order of execution for search components will be the following:
The following is an example declaration of StandardRequestHandler
:
<requestHandler name="/jazz" class="solr. StandardRequestHandler
">
<!-- parameters that will be always applied to the incoming requests -->
<lst name="invariants">
<int name="rows">10</int>
</lst>
<!-- parameters that will be always added to the incoming requests -->
<lst name="appends">
<int name="fq">genre:jazz</int>
</lst>
<!-- default settings that can be overridden by the incoming requests -->
<lst name="defaults">
<str name="sort">title asc</str>
<str name="echoParams">explicit</str>
<str name="q">*:*</str>
<bool name="facet">false</bool>
</lst>
<!—This is a custom search component that will run after the default component chain-->
<arr name="last-components">
<str>prices</str>
</arr>
</requestHandler>
The request handlers and the search components involved in the chain accept several parameters to drive their execution logic. These parameters (with corresponding values) can be declared in three different sections:
All sections are optional, so you can have no parameters configured for a given handler and allow the incoming requests to define them. This is an example of a handler configuration:
<lst name="defaults"> <str name="defType">edismax</str> </lst> <lst name="appends"> <str name="facet.field">artist</str> <str name="facet">genre</str> </lst> <lst name="invariants"> <str name="wt">json</str> <bool name="facet">true</bool> </lst>
RealTimeGetHandler
is basically a SearchHandler
subclass that adds RealTimeSearchComponent
to the search request execution. In this way, it's possible to retrieve the latest version of softly committed documents by specifying their identifiers.
In order to enable such a component, you must turn the update log feature on, in solrconfig.xml
:
<updateHandler class="solr.DirectUpdateHandler2"> <updateLog> <str name="dir">${solr.ulog.dir:}</str> </updateLog> … </updateHandler>
Then the request handler can be declared and configured using the procedure that we saw in the previous section:
<requestHandler name="/get" class="solr.RealTimeGetHandler"> … </requestHandler>
This handler accepts an additional id
or ids
parameter that allows us to specify the identifiers of the documents we want to retrieve. The id
parameter accepts one identifier and can be repeated in requests. The ids
parameter accepts a comma-separated list of identifiers.
18.225.72.245