Search handler

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.

Standard request handler

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.

Search components

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

query

QueryComponent

facet

FacetComponent

mlt

MoreLikeThisComponent

highlight

HighlightComponent

stats

StatsComponent

debug

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:

  • Components declared as "first-components" (optional).
  • Components declared as "components" In their absence, the default chain will be used.
  • Components declared as "last-components" (optional).

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>

Query parameters

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:

  • defaults: Parameter values will be used unless overridden by incoming requests
  • appends: Parameter values will appended to each request
  • invariants: Parameter values will be always be applied and cannot be overridden by incoming requests or by the values declared in defaults and append 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

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.

Tip

Once the example Solr instance is up, this handler responds to /get requests.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.225.72.245