All the parameters seen till now can also be used to configure a new request handler.
- It's very simple to configure new search handlers, and add some default parameters to them. For example we could add a new configuration to our
paintingscore (to itssolrconfig.xmlfile):<requestHandler name="/search_by_width/" class="solr.StandardRequestHandler"> <lst name="defaults"> <int name="rows">3</int> <str name="wt">json</str> <str name="indent">true</str> <bool name="omitHeader">true</bool> </lst> <lst name="appends"> <str name="fq">abstract:painting AND sea</str> <str name="fq">title:* AND artist:*</str> </lst> <lst name="invariants"> <str name="fl">title,artist</str> <str name="fq">width:{0 TO 4]</str> </lst> </requestHandler> - This time we will not need to re-import data, as we are only adding a new handler to a predefined
solrconfig.xmlfile. We restart the core, and then perform the following query:>> curl -X GET 'http://localhost:8983/solr/paintings/search_by_width?q=*:*' - We will receive an output as shown in the following image:
Here, we are obtaining only the first three documents from the results.
In our configuration, we will use three different list of parameter values (<lst />), containing values that will be defined by their data types (str, bool, int, and so on). We can recognize the following three different parts:
- default: We use this part to define default values for various parameters, in particular regarding the format for the results. These values can be easily overridden during query, as we normally do.
- appends: Here we put parameters that should be appended to every request. In our case, we want to consider only documents containing the term
paintingandseain their abstract field. We also want to be sure that every document in the result has a value for the fieldsartistandtitle. Notice that these choices are restrictive and they should be read in the beginning. We can add as many parameter choices as we like to obtain narrower searches. - invariants: In this part, we specify fields that we don't want to be changed. In our case, we want to search documents describing paintings with a specific size proportion and we will output only two predefined fields (artist and title), no matter what
flvalues are passed during querying.
We can look at http://wiki.apache.org/solr/SearchHandler#Configuration for a complete reference.
Both the fl and the fq parameters can be passed many times as we would need to add a new criteria at the time. For example, by using some client library for frontend. However, in the invariant part, only the fq parameter can be customized during query.
A Response Writer
is a component to write results from a query in a different way. Using the writer type parameter wt, we can obtain results in some different formats, including CSV, XML, json, and also php-like formatted array. But, depending on how it's made, Response Writer can be also used to create different presentations of data. It can be managed internally on the server by Solr using XSLT, velocity templates, or other technologies.
You can read more on the reference guide at:
https://cwiki.apache.org/confluence/display/solr/Response+Writers
Tip
One of the most interesting alternative Response Writer is the VelocityResponse Writer . For more information on VelocityResponseWriter, visit https://wiki.apache.org/solr/VelocityResponseWriter). We will not use it here as it involves a little knowledge of the velocity syntax and writing some specific templates. But, it is a very good tool for prototyping. I suggest you look at it when you are a bit more confident about Solr configuration, proceeding one step at a time.
We will focus mainly on directly using the services for our purposes, so that you can define your own frontend on those. For example, it's simple to construct a basic example of frontend showing only a list of documents preview using the Solrstrap JavaScript library:
You can find this small draft constructed on a single HTML page by following the path /SolrStarterBook/test/chp04/paintings/html, which can be used as a skeleton for starting your own experiments with customizations. In the example shown here, you can easily see a structured version of the results obtained from the server by using the browser (Chrome, in this case) console.
We have already seen and used the couple start and rows that gives us the possibility to play with the pagination of results. We also did a few tests with the fields list parameter fl and the parameter fq to restrict the collection of documents on which we perform searches.
The pageDoc and pageScore parameters expose two different level of scores, and are important if you need to select documents with a score value higher than a certain amount.
At last, we can simply hide the header part of a response with the omitHeader parameter. This could be useful when in production.
We can obtain a simple remainder of the main section of a common response by executing the following simple query:
>> curl -X GET 'http://localhost:8983/solr/paintings/select?q=*:*&rows=0&facet=true&mlt=true&mlt.fl=&highlight=true&stats=true&debug=true&wt=json'
This simply returns a simple structure for a common response:
Here, we can easily recognize the response section that will generally contain the list of the docs returned. In this case, the result is empty (like the other lists for faceted search highlights, and so on) because of the use of rows=0 for simplicity.
Apart from the initial responseHeader section, the latter sections (facet_counts, moreLikeThis, stats, and debug) correspond to specific search handlers that we can also activate using the qt parameter. In this case, we expose the response via the json formatter wt=json, but we can also switch to other kind of representations, as you already know.