The Extended DisMax (eDisMax) query parser is an improved version of the DisMax query parser. In addition to supporting all the DisMax query parser parameters, Extended Dismax:
- supports the full Lucene query parser syntax.
- supports queries such as AND, OR, NOT, -, and +.
- treats "and" and "or" as "AND" and "OR" in Lucene syntax mode.
- respects the 'magic field' names _val_ and _query_. These are not a real fields in schema.xml, but if used it helps do special things (like a function query in the case of _val_ or a nested query in the case of _query_). If _val_ is used in a term or phrase query, the value is parsed as a function.
- includes improved smart partial escaping in the case of syntax errors; fielded queries, +/-, and phrase queries are still supported in this mode.
- improves proximity boosting by using word shingles; you do not need the query to match all words in the document before proximity boosting is applied.
- includes advanced stopword handling: stopwords are not required in the mandatory part of the query but are still used in the proximity boosting part. If a query consists of all stopwords, such as "to be or not to be", then all words are required.
- includes improved boost function: in Extended DisMax, the boost function is a multiplier rather than an addend, improving your boost results; the additive boost functions of DisMax (bf and bq) are also supported.
- supports pure negative nested queries: queries such as +foo (-foo) will match all documents.
- lets you specify which fields the end user is allowed to query, and to disallow direct fielded searches.
|The Extended DisMax query parser is still under active development, in fact many changes were introduced for Solr 4. However, many organizations are already using it in production with great success.|
In addition to all the DisMax parameters, Extended DisMax includes these query parameters:
A multivalued list of strings parsed as queries with scores multiplied by the score from the main query for all matching documents. This parameter is shorthand for wrapping the query produced by eDisMax using the BoostQParserPlugin
A Boolean parameter indicating if lowercase "and" and "or" should be treated the same as operators "AND" and "OR".
Default amount of slop on phrase queries built with pf, pf2 and/or pf3 fields (affects boosting).
A multivalued list of fields with optional weights, based on pairs of word shingles.
Default amount of slop on phrase queries built with pf, pf2 and/or pf3 fields (affects boosting). New with Solr 4, it is similar to ps but sets default slop factor for pf2. If not specified, ps is used.
A multivalued list of fields with optional weights, based on triplets of word shingles. Similar to pf, except that instead of building a phrase per field out of all the words in the input, it builds a set of phrases for each field out of each triplet of word shingles.
New with Solr 4. As with ps but sets default slop factor for pf3. If not specified, ps will be used.
A Boolean parameter indicating if the StopFilterFactory configured in the query analyzer should be respected when parsing the query: if it is false, then the StopFilterFactory in the query analyzer is ignored.
Specifies which schema fields the end user is allowed to explicitly query. This parameter supports wildcards. The default is to allow all fields, equivalent to &uf=*. To allow only title field, use &uf=title. To allow title and all fields ending with _s, use &uf=title,*_s. To allow all fields except title, use &uf=*-title. To disallow all fielded searches, use &uf=-*.
Boost the result of the query term "hello" based on the document's popularity:
Search for iPods OR video:
Search across multiple fields, specifying (via boosts) how important each field is relative each other:
You can boost results that have a field that matches a specific value:
Using the "mm" param, 1 and 2 word queries require that all of the optional clauses match, but for queries with three or more clauses one missing clause is allowed:
Negative query boosts have been supported at the "Query" object level for a long time (resulting in negative scores for matching documents). Now the QueryParsers have been updated to handle this too.
Dismax and Edismax can run queries against all query fields, and also run a query in the form of a phrase against the phrase fields. (This will work only for boosting documents, not actually for matching.) However, that phrase query can have a 'slop,' which is the distance between the terms of the query while still considering it a phrase match. For example:
With these parameters, the Dismax Query Parser generates a query that looks something like this:
But it also generates another query that will only be used for boosting results:
Thus, any document that has the terms "foo" and "bar" will match; however if some of those documents have both of the terms as a phrase, it will score much higher because it's more relevant.
If you add the parameter ps (phrase slop), the second query will instead be:
This means that if the terms "foo" and "bar" appear in the document with less than 10 terms between each other, the phrase will match. For example the doc that says:
will match the phrase query.
How does one use phrase slop? Usually it is configured in the request handler (in solrconfig).
With query slop (qs) the concept is similar, but it applies to explicit phrase queries from the user. For example, if you want to search for a name, you could enter:
A document that contains "Hans Anderson" will match, but a document that contains the middle name "Christian" or where the name is written with the last name first ("Anderson, Hans") won't. For those cases one could configure the query field qs, so that even if the user searches for an explicit phrase query, a slop is applied.
Finally, edismax contains not only a phrase fields (pf) parameters, but also phrase and query fields 2 and 3. You can use those fields for setting different fields or boosts. Each of those can use a different phrase slop.
If the 'magic field' name _val_ is used in a term or phrase query, the value is parsed as a function.
The Solr Query Parser's use of _val_ and _query_ differs from the Lucene Query Parser in the following ways:
- If the magic field name _val_ is used in a term or phrase query, the value is parsed as a function.
- It provides a hook into FunctionQuery syntax. Quotes are necessary to encapsulate the function when it includes parentheses. For example:
- The Solr Query Parser offers nested query support for any type of query parser (via QParserPlugin). Quotes are often necessary to encapsulate the nested query if it contains reserved characters. For example:
Although not technically a syntax difference, note that if you use the Solr DateField type, any queries on those fields (typically range queries) should use either the Complete ISO 8601 Date syntax that field supports, or the DateMath Syntax to get relative dates. For example:
|TO must be uppercase, or Solr will report a 'Range Group' error.|