Time for action – writing a simple solrconfig.xml file

In the solrconfig.xml file we can define how to manage requests and data manipulation for the user. This file can contain a number of different configurations. Here we can plug-in specific components and define how they are integrated within the default workflow of the data. Their typical uses include helping API with suggestions to expose, and to customize them for different language localizations.

The basic structure will more or less include the following elements:

<config>
  <requestHandler name='standard' … />
  <requestHandler name='/update' ... />
  <requestHandler name='/admin/' … />
  <updateHandler class='solr.DirectUpdateHandler2' … />
   ...
</config>

Steps for writing a simple solrconfig.xml file are as follows:

  1. Using this structure as a reference, let's write a basic sorlconfig.xml file, and save it, for example, save it under the path /SolrStarterBook/solr-app/chp02/simple/conf/.

    Tip

    While you follow the instruction to reproduce a full example in the repository, I suggest you create your own parallel version of the same example from scratch and simply adopt a different name for it (for example, something like simple_ex), so that you can still look at the working example if you have problems.

  2. The created solrconfig.xml file will look as shown in the following code:
    <?xml version='1.0' encoding='UTF-8' ?>
<config>
  <luceneMatchVersion>LUCENE_45</luceneMatchVersion>

  <requestHandler name='standard' class='solr.StandardRequestHandler' default='true' />
  <requestHandler name='/update' class='solr.UpdateRequestHandler' />

  <requestHandler name='/admin/' class='org.apache.solr.handler.admin.AdminHandlers' />
  <admin>
    <defaultQuery>*:*</defaultQuery>
  </admin>
</config>
  3. In a standard configuration there are a few more tags, but I have omitted them here as we don't need them at the moment.

What just happened?

Solr exposes various components as services, in order to provide a different kind of functionality. These components are managed with the RequestHandler components:

  • Query handler: this is a standard handler implicitly mapped on the path /select, unless we decide to explicitly use another name. We have already seen this handler in action, as it was the one that received our first test query.
  • Update handler: This is explicitly mapped to the path /update. This is used to receive new data to be indexed. Please note that the data to be indexed in Solr are generally called documents, and it's important to distinguish them from the original data we want to search over. A Solr document is indeed a flat, unstructured sequence of the indexed metadata we want to use to represent a specific resource in our search domain.
  • Admin handler: This is explicitly mapped to the path /admin. This is essential for using the admin web interface and having access to statistics, debug, and so on. Somewhat related to this definition is the definition of the default query to use in the admin interface.

In a common configuration there can be other exposed services such as /ping (used for checking if a core is still correctly running), but for now I decided to omit them to keep things simple and focus on understanding how the various sections are designed.

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

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