Every now and than there is a question appearing on the mailing list – what type of query parsers are available in Solr. So we decided to make such a list with a short description about each of the query parsers available. If you are interested to see what Solr has to offer, please read the rest of this post.
Let’s start with the list
By using the defType parameter during query time, we can specify which query parser should be used as the default one during query execution. However, as you’ll see in the examples this is not the only way – we can also use local params. However, before short description of each of the query parsers available in Solr we would like to list them all. In Solr 4.4 the following query parsers can be used:
- lucene
- lucenePlusSort
- func
- prefix
- boost
- dismax
- edismax
- field
- raw
- term
- query
- frange
- geofilt
- bbox
- join
- surround
- switch
- maxscore
Lucene Query Parser – lucene
Default query parser used by Solr that allows us to use Lucene query syntax to make queries (with some small differences that are mentioned on Solr wiki: http://wiki.apache.org/solr/SolrQuerySyntax). An example query made with this parser can look like this: q=+title:harry +category:books
Old Lucene Query Parser – lucenePlusSort
Old Lucene query parser, that is currently rarely used. It allowed after query sorting specification, that is marked as deprecated, for example: q={!lucenePlusSort}title:harry;price asc
Function Query Parser – func
Query parser that allows us to use function queries (http://wiki.apache.org/solr/FunctionQuery) in our queries. For example we can make calculations during queries – q={!func}add($value1,$value2)&value1=max(price,100)&value2=1.0.
Prefix Query Parser – prefix
Parser that is not field type aware, so no analysis is done on the input text. It allows us to make prefix queries. For example a query like q={!prefix}har is more of less equal to q=har* in Lucene query parser syntax.
Boost Query Parser – boost
Boost query parser allows us to create boosting queries from the input value. When using local params we have our query that should be boosted and the b parameter – the query that will be used for boosting. For example {!boost b=recip(ms(NOW,published),3.16e-11,1,1)}harry will cause the harry query to be boosted on the basis of publication date.
Dismax Query Parser – dismax
Query parser that supports simplified version of Lucene query syntax (for example field names are not allowed) and creates disjunction max queries from each term from the user input against all the fields provided in the qf parameter. It allows specifying how much terms should match (the mm parameter) and how lower scoring query elements should be treated (tie parameter). All the parameters supported by dismax query parser (and its overview) can be found at: http://wiki.apache.org/solr/DisMaxQParserPlugin.
Extended Dismax Query Parser – edismax
Extended version of the mentioned dismax query parser, which allows us to use field names in the main query. It was designed to provide users with the possibility of specifying more advanced queries in comparison to dismax query parser. All the parameters supported by extended dismax query parser (and its overview) can be found at: http://wiki.apache.org/solr/ExtendedDisMax.
Field Query Parser – field
Field query parser allows us to make a query against a field, applying text analysis and constructing a phrase query if appropriate, for example: {!field f=title}harry potter. This is more or less equivalent to Lucene query parser expression of title:”harry potter”.
Raw Query Parser – raw
Query parser which allows us to pass a term, which will not be analysed or transformed in any way. For example, the {!raw f=title}harry will create a term query against the title field with the exact value of harry, without any analysis done.
Term Query Parser – term
Query parser useful for making filters with human readable terms, like the ones for faceting or terms component, for example {!term f=category}book. Please remember, that the term given for the term query parser will not be analyzed or transformed.
Nested Query Parser – query
A query parser that allows us to specify a nested query, with the ability to change its type in the nested query. For example, the following query {!query defType=func v=$query}&$query=max(price,100) would result in function query defined in the query parameter, however if we would change the query parameter to $query={!term f=category}book, the term query parser would be used, so the function query parser would be overwritten. This query parser can be useful in situations, when we allow users to reference values stored in handlers configurations.
Function Range Query Parser – frange
Query parser that allows us to create a range query over a function value (we’ve wrote about it long time ago – http://solr.pl/en/2011/05/30/quick-look-frange/). It exposes four parameters l (lower bound), u (upper bound), incl (include lower bound), incu (include upper bound) which allows us to configure its behavior. An example query using this query parser could look like this: {!frange l=10 u=12 incl=true incu=true}sum(price,rate).
Spatial Filter Query Parser – geofilt
Spatial filter query parser allows us to make queries which results will be narrowed to documents that are in the distance from a given point. For example, by running a query like q=*:*&fq={!geofilt pt=52.14,21.10 sfield=location d=50} we will find documents that are more or less in Warsaw, Poland 🙂 You can find more about geofilt query parser on Solr wiki – http://wiki.apache.org/solr/SpatialSearch#geofilt_-_The_distance_filter.
Spatial Box Query Parser – bbox
Similar to geofilt query parser, the spatial box query parser allows us to narrow down query results to only those documents, that are in the location of interest, but because of approximations it is less demanding, when it comes to processing power (however you may get slightly more results when comparing to geofilt). An example query would be very similar to the one shown in geofilt example: q=*:*&fq={!bbox pt=52.14,21.10 sfield=location d=50}. You can find more about it on Solr wiki – http://wiki.apache.org/solr/SpatialSearch#bbox_-_Bounding-box_filter.
Join Query Parser – join
Query parser that allows us to make pseudo joins between documents, both coming from the same core and ones that are between different cores, for example: q={!join from=parent to=id}color:Yellow. You can see an example and read more about this query parser in http://solr.pl/en/2011/02/21/waiting-for-4-0-solr-2272-solr-and-join-functionality/.
Surround Query Parser – surround
Contrib query parser, that allows us to use span query in Solr. You can read more about this query parser at: http://wiki.apache.org/solr/SurroundQueryParser. We will try to write a blog post about how span queries work both in Lucene and Solr – in general it allows searching for terms or phrases that use position information.
Switch Query Parser – switch
The logic of switch query parser is quite simple – allow processing of a simple logic on the Solr side and add it as a sub-query. You can find an example usage and read more about this query parser at: http://solr.pl/en/2013/06/03/switch-query-parser-quick-look/.
Max Score Query Parser – maxscore
Very similar to Lucene query parser (accept all of its parameters), but the score of the documents is not the sum of all scoring elements, but the score of the maximum scoring element. It allows to use the tie parameter which defines how the final document score will be calculated (similar to how tie parameter works in dismax query parser and extended dismax query parser). For tie=0.0 only the score of the maximum scoring element will be used, for tie=1.0 a sum of all scoring elements will be given to a document. An example query using this parser can look like this: q=potter {!maxscore v=’harry’}. You can read more about tie parameter at http://solr.pl/en/2012/02/06/what-can-we-use-dismax-tie-parameter-for/.
Small summary
As you can see Solr provides a wide range of query parsers that can be included in our queries. With that we can make complicated queries, that will leverage different functionalities of Solr. However there is one thing to remember – the more complicated the query is, the more processing power it will require. Keep that in mind when constructing your queries.