You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by da...@apache.org on 2017/07/18 05:14:10 UTC
[18/33] lucene-solr:feature/autoscaling: SOLR-11050,
SOLR-10892: last set of Confluence-style anchors removed and
parameter tables obliterated
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/spell-checking.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/spell-checking.adoc b/solr/solr-ref-guide/src/spell-checking.adoc
index b46c8a1..20ec5e0 100644
--- a/solr/solr-ref-guide/src/spell-checking.adoc
+++ b/solr/solr-ref-guide/src/spell-checking.adoc
@@ -22,15 +22,12 @@ The SpellCheck component is designed to provide inline query suggestions based o
The basis for these suggestions can be terms in a field in Solr, externally created text files, or fields in other Lucene indexes.
-[[SpellChecking-ConfiguringtheSpellCheckComponent]]
== Configuring the SpellCheckComponent
-[[SpellChecking-DefineSpellCheckinsolrconfig.xml]]
=== Define Spell Check in solrconfig.xml
The first step is to specify the source of terms in `solrconfig.xml`. There are three approaches to spell checking in Solr, discussed below.
-[[SpellChecking-IndexBasedSpellChecker]]
==== IndexBasedSpellChecker
The `IndexBasedSpellChecker` uses a Solr index as the basis for a parallel index used for spell checking. It requires defining a field as the basis for the index terms; a common practice is to copy terms from some fields (such as `title`, `body`, etc.) to another field created for spell checking. Here is a simple example of configuring `solrconfig.xml` with the `IndexBasedSpellChecker`:
@@ -57,7 +54,6 @@ The `spellcheckIndexDir` defines the location of the directory that holds the sp
Finally, _buildOnCommit_ defines whether to build the spell check index at every commit (that is, every time new documents are added to the index). It is optional, and can be omitted if you would rather set it to `false`.
-[[SpellChecking-DirectSolrSpellChecker]]
==== DirectSolrSpellChecker
The `DirectSolrSpellChecker` uses terms from the Solr index without building a parallel index like the `IndexBasedSpellChecker`. This spell checker has the benefit of not having to be built regularly, meaning that the terms are always up-to-date with terms in the index. Here is how this might be configured in `solrconfig.xml`
@@ -89,9 +85,8 @@ Because this spell checker is querying the main index, you may want to limit how
The `maxInspections` parameter defines the maximum number of possible matches to review before returning results; the default is 5. `minQueryLength` defines how many characters must be in the query before suggestions are provided; the default is 4.
-At first, spellchecker analyses incoming query words by looking up them in the index. Only query words, which are absent in index or too rare ones (below `maxQueryFrequency` ) are considered as misspelled and used for finding suggestions. Words which are frequent than `maxQueryFrequency` bypass spellchecker unchanged. After suggestions for every misspelled word are found they are filtered for enough frequency with `thresholdTokenFrequency` as boundary value. These parameters (`maxQueryFrequency` and `thresholdTokenFrequency`) can be a percentage (such as .01, or 1%) or an absolute value (such as 4).
+At first, spellchecker analyses incoming query words by looking up them in the index. Only query words, which are absent in index or too rare ones (below `maxQueryFrequency`) are considered as misspelled and used for finding suggestions. Words which are frequent than `maxQueryFrequency` bypass spellchecker unchanged. After suggestions for every misspelled word are found they are filtered for enough frequency with `thresholdTokenFrequency` as boundary value. These parameters (`maxQueryFrequency` and `thresholdTokenFrequency`) can be a percentage (such as .01, or 1%) or an absolute value (such as 4).
-[[SpellChecking-FileBasedSpellChecker]]
==== FileBasedSpellChecker
The `FileBasedSpellChecker` uses an external file as a spelling dictionary. This can be useful if using Solr as a spelling server, or if spelling suggestions don't need to be based on actual terms in the index. In `solrconfig.xml`, you would define the searchComponent as so:
@@ -120,7 +115,6 @@ The differences here are the use of the `sourceLocation` to define the location
In the previous example, _name_ is used to name this specific definition of the spellchecker. Multiple definitions can co-exist in a single `solrconfig.xml`, and the _name_ helps to differentiate them. If only defining one spellchecker, no name is required.
====
-[[SpellChecking-WordBreakSolrSpellChecker]]
==== WordBreakSolrSpellChecker
`WordBreakSolrSpellChecker` offers suggestions by combining adjacent query terms and/or breaking terms into multiple words. It is a `SpellCheckComponent` enhancement, leveraging Lucene's `WordBreakSpellChecker`. It can detect spelling errors resulting from misplaced whitespace without the use of shingle-based dictionaries and provides collation support for word-break errors, including cases where the user has a mix of single-word spelling errors and word-break errors in the same query. It also provides shard support.
@@ -145,7 +139,6 @@ Some of the parameters will be familiar from the discussion of the other spell c
The spellchecker can be configured with a traditional checker (ie: `DirectSolrSpellChecker`). The results are combined and collations can contain a mix of corrections from both spellcheckers.
-[[SpellChecking-AddIttoaRequestHandler]]
=== Add It to a Request Handler
Queries will be sent to a <<query-syntax-and-parsing.adoc#query-syntax-and-parsing,RequestHandler>>. If every request should generate a suggestion, then you would add the following to the `requestHandler` that you are using:
@@ -173,151 +166,86 @@ Here is an example with multiple dictionaries:
</requestHandler>
----
-[[SpellChecking-SpellCheckParameters]]
== Spell Check Parameters
-The SpellCheck component accepts the parameters described in the table below.
-
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
-
-[cols="30,70",options="header"]
-|===
-|Parameter |Description
-|<<SpellChecking-ThespellcheckParameter,spellcheck>> |Turns on or off SpellCheck suggestions for the request. If *true*, then spelling suggestions will be generated.
-|<<SpellChecking-Thespellcheck.qorqParameter,spellcheck.q or q>> |Selects the query to be spellchecked.
-|<<SpellChecking-Thespellcheck.buildParameter,spellcheck.build>> |Instructs Solr to build a dictionary for use in spellchecking.
-|<<SpellChecking-Thespellcheck.collateParameter,spellcheck.collate>> |Causes Solr to build a new query based on the best suggestion for each term in the submitted query.
-|<<SpellChecking-Thespellcheck.maxCollationsParameter,spellcheck.maxCollations>> |This parameter specifies the maximum number of collations to return.
-|<<SpellChecking-Thespellcheck.maxCollationTriesParameter,spellcheck.maxCollationTries>> |This parameter specifies the number of collation possibilities for Solr to try before giving up.
-|<<SpellChecking-Thespellcheck.maxCollationEvaluationsParameter,spellcheck.maxCollationEvaluations>> |This parameter specifies the maximum number of word correction combinations to rank and evaluate prior to deciding which collation candidates to test against the index.
-|<<SpellChecking-Thespellcheck.collateExtendedResultsParameter,spellcheck.collateExtendedResults>> |If true, returns an expanded response detailing the collations found. If `spellcheck.collate` is false, this parameter will be ignored.
-|<<SpellChecking-Thespellcheck.collateMaxCollectDocsParameter,spellcheck.collateMaxCollectDocs>> |The maximum number of documents to collect when testing potential Collations
-|<<SpellChecking-Thespellcheck.collateParam._ParameterPrefix,spellcheck.collateParam.*>> |Specifies param=value pairs that can be used to override normal query params when validating collations
-|<<SpellChecking-Thespellcheck.countParameter,spellcheck.count>> |Specifies the maximum number of spelling suggestions to be returned.
-|<<SpellChecking-Thespellcheck.dictionaryParameter,spellcheck.dictionary>> |Specifies the dictionary that should be used for spellchecking.
-|<<SpellChecking-Thespellcheck.extendedResultsParameter,spellcheck.extendedResults>> |Causes Solr to return additional information about spellcheck results, such as the frequency of each original term in the index (origFreq) as well as the frequency of each suggestion in the index (frequency). Note that this result format differs from the non-extended one as the returned suggestion for a word is actually an array of lists, where each list holds the suggested term and its frequency.
-|<<SpellChecking-Thespellcheck.onlyMorePopularParameter,spellcheck.onlyMorePopular>> |Limits spellcheck responses to queries that are more popular than the original query.
-|<<SpellChecking-Thespellcheck.maxResultsForSuggestParameter,spellcheck.maxResultsForSuggest>> |The maximum number of hits the request can return in order to both generate spelling suggestions and set the "correctlySpelled" element to "false".
-|<<SpellChecking-Thespellcheck.alternativeTermCountParameter,spellcheck.alternativeTermCount>> |The count of suggestions to return for each query term existing in the index and/or dictionary.
-|<<SpellChecking-Thespellcheck.reloadParameter,spellcheck.reload>> |Reloads the spellchecker.
-|<<SpellChecking-Thespellcheck.accuracyParameter,spellcheck.accuracy>> |Specifies an accuracy value to help decide whether a result is worthwhile.
-|<<spellcheck_DICT_NAME,spellcheck.<DICT_NAME>.key>> |Specifies a key/value pair for the implementation handling a given dictionary.
-|===
-
-[[SpellChecking-ThespellcheckParameter]]
-=== The spellcheck Parameter
-
-This parameter turns on SpellCheck suggestions for the request. If *true*, then spelling suggestions will be generated.
-
-[[SpellChecking-Thespellcheck.qorqParameter]]
-=== The spellcheck.q or q Parameter
-
-This parameter specifies the query to spellcheck. If `spellcheck.q` is defined, then it is used; otherwise the original input query is used. The `spellcheck.q` parameter is intended to be the original query, minus any extra markup like field names, boosts, and so on. If the `q` parameter is specified, then the `SpellingQueryConverter` class is used to parse it into tokens; otherwise the <<tokenizers.adoc#white-space-tokenizer,`WhitespaceTokenizer`>> is used. The choice of which one to use is up to the application. Essentially, if you have a spelling "ready" version in your application, then it is probably better to use `spellcheck.q`. Otherwise, if you just want Solr to do the job, use the `q` parameter.
-
-[NOTE]
-====
-The SpellingQueryConverter class does not deal properly with non-ASCII characters. In this case, you have either to use `spellcheck.q`, or implement your own QueryConverter.
-====
-
-[[SpellChecking-Thespellcheck.buildParameter]]
-=== The spellcheck.build Parameter
-
-If set to *true*, this parameter creates the dictionary that the SolrSpellChecker will use for spell-checking. In a typical search application, you will need to build the dictionary before using the SolrSpellChecker. However, it's not always necessary to build a dictionary first. For example, you can configure the spellchecker to use a dictionary that already exists.
-
-The dictionary will take some time to build, so this parameter should not be sent with every request.
+The SpellCheck component accepts the parameters described below.
-[[SpellChecking-Thespellcheck.reloadParameter]]
-=== The spellcheck.reload Parameter
+`spellcheck`::
+This parameter turns on SpellCheck suggestions for the request. If `true`, then spelling suggestions will be generated. This is required if spell checking is desired.
-If set to true, this parameter reloads the spellchecker. The results depend on the implementation of `SolrSpellChecker.reload()`. In a typical implementation, reloading the spellchecker means reloading the dictionary.
+`spellcheck.q` or `q`::
+This parameter specifies the query to spellcheck.
++
+If `spellcheck.q` is defined, then it is used; otherwise the original input query is used. The `spellcheck.q` parameter is intended to be the original query, minus any extra markup like field names, boosts, and so on. If the `q` parameter is specified, then the `SpellingQueryConverter` class is used to parse it into tokens; otherwise the <<tokenizers.adoc#white-space-tokenizer,`WhitespaceTokenizer`>> is used.
++
+The choice of which one to use is up to the application. Essentially, if you have a spelling "ready" version in your application, then it is probably better to use `spellcheck.q`. Otherwise, if you just want Solr to do the job, use the `q` parameter.
-[[SpellChecking-Thespellcheck.countParameter]]
-=== The spellcheck.count Parameter
+NOTE: The `SpellingQueryConverter` class does not deal properly with non-ASCII characters. In this case, you have either to use `spellcheck.q`, or implement your own QueryConverter.
-This parameter specifies the maximum number of suggestions that the spellchecker should return for a term. If this parameter isn't set, the value defaults to 1. If the parameter is set but not assigned a number, the value defaults to 5. If the parameter is set to a positive integer, that number becomes the maximum number of suggestions returned by the spellchecker.
-
-[[SpellChecking-Thespellcheck.onlyMorePopularParameter]]
-=== The spellcheck.onlyMorePopular Parameter
-
-If *true*, Solr will to return suggestions that result in more hits for the query than the existing query. Note that this will return more popular suggestions even when the given query term is present in the index and considered "correct".
-
-[[SpellChecking-Thespellcheck.maxResultsForSuggestParameter]]
-=== The spellcheck.maxResultsForSuggest Parameter
-
-For example, if this is set to 5 and the user's query returns 5 or fewer results, the spellchecker will report "correctlySpelled=false" and also offer suggestions (and collations if requested). Setting this greater than zero is useful for creating "did-you-mean?" suggestions for queries that return a low number of hits.
+`spellcheck.build`::
+If set to `true`, this parameter creates the dictionary to be used for spell-checking. In a typical search application, you will need to build the dictionary before using the spell check. However, it's not always necessary to build a dictionary first. For example, you can configure the spellchecker to use a dictionary that already exists.
++
+The dictionary will take some time to build, so this parameter should not be sent with every request.
-[[SpellChecking-Thespellcheck.alternativeTermCountParameter]]
-=== The spellcheck.alternativeTermCount Parameter
+`spellcheck.reload`::
+If set to `true`, this parameter reloads the spellchecker. The results depend on the implementation of `SolrSpellChecker.reload()`. In a typical implementation, reloading the spellchecker means reloading the dictionary.
-Specify the number of suggestions to return for each query term existing in the index and/or dictionary. Presumably, users will want fewer suggestions for words with docFrequency>0. Also setting this value turns "on" context-sensitive spell suggestions.
+`spellcheck.count`::
+This parameter specifies the maximum number of suggestions that the spellchecker should return for a term. If this parameter isn't set, the value defaults to `1`. If the parameter is set but not assigned a number, the value defaults to `5`. If the parameter is set to a positive integer, that number becomes the maximum number of suggestions returned by the spellchecker.
-[[SpellChecking-Thespellcheck.extendedResultsParameter]]
-=== The spellcheck.extendedResults Parameter
+`spellcheck.onlyMorePopular`::
+If `true`, Solr will to return suggestions that result in more hits for the query than the existing query. Note that this will return more popular suggestions even when the given query term is present in the index and considered "correct".
-This parameter causes to Solr to include additional information about the suggestion, such as the frequency in the index.
+`spellcheck.maxResultsForSuggest`::
+If, for example, this is set to `5` and the user's query returns 5 or fewer results, the spellchecker will report "correctlySpelled=false" and also offer suggestions (and collations if requested). Setting this greater than zero is useful for creating "did-you-mean?" suggestions for queries that return a low number of hits.
-[[SpellChecking-Thespellcheck.collateParameter]]
-=== The spellcheck.collate Parameter
+`spellcheck.alternativeTermCount`::
+Defines the number of suggestions to return for each query term existing in the index and/or dictionary. Presumably, users will want fewer suggestions for words with docFrequency>0. Also, setting this value enables context-sensitive spell suggestions.
-If *true*, this parameter directs Solr to take the best suggestion for each token (if one exists) and construct a new query from the suggestions. For example, if the input query was "jawa class lording" and the best suggestion for "jawa" was "java" and "lording" was "loading", then the resulting collation would be "java class loading".
+`spellcheck.extendedResults`::
+If `true`, this parameter causes to Solr to return additional information about spellcheck results, such as the frequency of each original term in the index (`origFreq`) as well as the frequency of each suggestion in the index (`frequency`). Note that this result format differs from the non-extended one as the returned suggestion for a word is actually an array of lists, where each list holds the suggested term and its frequency.
-The spellcheck.collate parameter only returns collations that are guaranteed to result in hits if re-queried, even when applying original `fq` parameters. This is especially helpful when there is more than one correction per query.
+`spellcheck.collate`::
+If `true`, this parameter directs Solr to take the best suggestion for each token (if one exists) and construct a new query from the suggestions.
++
+For example, if the input query was "jawa class lording" and the best suggestion for "jawa" was "java" and "lording" was "loading", then the resulting collation would be "java class loading".
++
+The `spellcheck.collate` parameter only returns collations that are guaranteed to result in hits if re-queried, even when applying original `fq` parameters. This is especially helpful when there is more than one correction per query.
NOTE: This only returns a query to be used. It does not actually run the suggested query.
-[[SpellChecking-Thespellcheck.maxCollationsParameter]]
-=== The spellcheck.maxCollations Parameter
-
-The maximum number of collations to return. The default is *1*. This parameter is ignored if `spellcheck.collate` is false.
+`spellcheck.maxCollations`::
+The maximum number of collations to return. The default is `1`. This parameter is ignored if `spellcheck.collate` is false.
-[[SpellChecking-Thespellcheck.maxCollationTriesParameter]]
-=== The spellcheck.maxCollationTries Parameter
+`spellcheck.maxCollationTries`::
+This parameter specifies the number of collation possibilities for Solr to try before giving up. Lower values ensure better performance. Higher values may be necessary to find a collation that can return results. The default value is `0`, which is equivalent to not checking collations. This parameter is ignored if `spellcheck.collate` is false.
-This parameter specifies the number of collation possibilities for Solr to try before giving up. Lower values ensure better performance. Higher values may be necessary to find a collation that can return results. The default value is `0`, which maintains backwards-compatible (Solr 1.4) behavior (do not check collations). This parameter is ignored if `spellcheck.collate` is false.
+`spellcheck.maxCollationEvaluations`::
+This parameter specifies the maximum number of word correction combinations to rank and evaluate prior to deciding which collation candidates to test against the index. This is a performance safety-net in case a user enters a query with many misspelled words. The default is `10000` combinations, which should work well in most situations.
-[[SpellChecking-Thespellcheck.maxCollationEvaluationsParameter]]
-=== The spellcheck.maxCollationEvaluations Parameter
+`spellcheck.collateExtendedResults`::
+If `true`, this parameter returns an expanded response format detailing the collations Solr found. The default value is `false` and this is ignored if `spellcheck.collate` is false.
-This parameter specifies the maximum number of word correction combinations to rank and evaluate prior to deciding which collation candidates to test against the index. This is a performance safety-net in case a user enters a query with many misspelled words. The default is *10,000* combinations, which should work well in most situations.
-
-[[SpellChecking-Thespellcheck.collateExtendedResultsParameter]]
-=== The spellcheck.collateExtendedResults Parameter
-
-If *true*, this parameter returns an expanded response format detailing the collations Solr found. The default value is *false* and this is ignored if `spellcheck.collate` is false.
-
-[[SpellChecking-Thespellcheck.collateMaxCollectDocsParameter]]
-=== The spellcheck.collateMaxCollectDocs Parameter
-
-This parameter specifies the maximum number of documents that should be collect when testing potential collations against the index. A value of *0* indicates that all documents should be collected, resulting in exact hit-counts. Otherwise an estimation is provided as a performance optimization in cases where exact hit-counts are unnecessary – the higher the value specified, the more precise the estimation.
-
-The default value for this parameter is *0*, but when `spellcheck.collateExtendedResults` is *false*, the optimization is always used as if a *1* had been specified.
-
-
-[[SpellChecking-Thespellcheck.collateParam._ParameterPrefix]]
-=== The spellcheck.collateParam.* Parameter Prefix
+`spellcheck.collateMaxCollectDocs`::
+This parameter specifies the maximum number of documents that should be collected when testing potential collations against the index. A value of `0` indicates that all documents should be collected, resulting in exact hit-counts. Otherwise an estimation is provided as a performance optimization in cases where exact hit-counts are unnecessary – the higher the value specified, the more precise the estimation.
++
+The default value for this parameter is `0`, but when `spellcheck.collateExtendedResults` is false, the optimization is always used as if `1` had been specified.
+`spellcheck.collateParam.*` Prefix::
This parameter prefix can be used to specify any additional parameters that you wish to the Spellchecker to use when internally validating collation queries. For example, even if your regular search results allow for loose matching of one or more query terms via parameters like `q.op=OR` and `mm=20%` you can specify override params such as `spellcheck.collateParam.q.op=AND&spellcheck.collateParam.mm=100%` to require that only collations consisting of words that are all found in at least one document may be returned.
-[[SpellChecking-Thespellcheck.dictionaryParameter]]
-=== The spellcheck.dictionary Parameter
-
-This parameter causes Solr to use the dictionary named in the parameter's argument. The default setting is "default". This parameter can be used to invoke a specific spellchecker on a per request basis.
-
-[[SpellChecking-Thespellcheck.accuracyParameter]]
-=== The spellcheck.accuracy Parameter
+`spellcheck.dictionary`::
+This parameter causes Solr to use the dictionary named in the parameter's argument. The default setting is `default`. This parameter can be used to invoke a specific spellchecker on a per request basis.
+`spellcheck.accuracy`::
Specifies an accuracy value to be used by the spell checking implementation to decide whether a result is worthwhile or not. The value is a float between 0 and 1. Defaults to `Float.MIN_VALUE`.
-
-[[spellcheck_DICT_NAME]]
-=== The spellcheck.<DICT_NAME>.key Parameter
-
-Specifies a key/value pair for the implementation handling a given dictionary. The value that is passed through is just `key=value` (`spellcheck.<DICT_NAME>.` is stripped off.
-
+`spellcheck.<DICT_NAME>.key`::
+Specifies a key/value pair for the implementation handling a given dictionary. The value that is passed through is just `key=value` (`spellcheck.<DICT_NAME>.` is stripped off).
++
For example, given a dictionary called `foo`, `spellcheck.foo.myKey=myValue` would result in `myKey=myValue` being passed through to the implementation handling the dictionary `foo`.
-[[SpellChecking-Example]]
-=== Example
+=== Spell Check Example
Using Solr's `bin/solr -e techproducts` example, this query shows the results of a simple request that defines a query using the `spellcheck.q` parameter, and forces the collations to require all input terms must match:
@@ -368,19 +296,15 @@ Results:
</lst>
----
-[[SpellChecking-DistributedSpellCheck]]
== Distributed SpellCheck
The `SpellCheckComponent` also supports spellchecking on distributed indexes. If you are using the SpellCheckComponent on a request handler other than "/select", you must provide the following two parameters:
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+`shards`::
+Specifies the shards in your distributed indexing configuration. For more information about distributed indexing, see <<distributed-search-with-index-sharding.adoc#distributed-search-with-index-sharding,Distributed Search with Index Sharding>>
-[cols="30,70",options="header"]
-|===
-|Parameter |Description
-|shards |Specifies the shards in your distributed indexing configuration. For more information about distributed indexing, see <<distributed-search-with-index-sharding.adoc#distributed-search-with-index-sharding,Distributed Search with Index Sharding>>
-|shards.qt |Specifies the request handler Solr uses for requests to shards. This parameter is not required for the `/select` request handler.
-|===
+`shards.qt`::
+Specifies the request handler Solr uses for requests to shards. This parameter is not required for the `/select` request handler.
For example:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/the-dismax-query-parser.adoc b/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
index 378fd93..1cb3014 100644
--- a/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
@@ -33,50 +33,25 @@ ____
Whether or not you remember this explanation, do remember that the DisMax Query Parser was primarily designed to be easy to use and to accept almost any input without returning an error.
-[[TheDisMaxQueryParser-DisMaxParameters]]
-== DisMax Parameters
+== DisMax Query Parser Parameters
-In addition to the common request parameter, highlighting parameters, and simple facet parameters, the DisMax query parser supports the parameters described below. Like the standard query parser, the DisMax query parser allows default parameter values to be specified in `solrconfig.xml`, or overridden by query-time values in the request.
-
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
-
-[cols="30,70",options="header"]
-|===
-|Parameter |Description
-|<<TheDisMaxQueryParser-TheqParameter,q>> |Defines the raw input strings for the query.
-|<<TheDisMaxQueryParser-Theq.altParameter,q.alt>> |Calls the standard query parser and defines query input strings, when the q parameter is not used.
-|<<TheDisMaxQueryParser-Theqf_QueryFields_Parameter,qf>> |Query Fields: specifies the fields in the index on which to perform the query. If absent, defaults to `df`.
-|<<TheDisMaxQueryParser-Themm_MinimumShouldMatch_Parameter,mm>> |Minimum "Should" Match: specifies a minimum number of clauses that must match in a query. If no 'mm' parameter is specified in the query, or as a default in `solrconfig.xml`, the effective value of the `q.op` parameter (either in the query or as a default in `solrconfig.xml`) is used to influence the behavior. If `q.op` is effectively AND'ed, then mm=100%; if `q.op` is OR'ed, then mm=1. Users who want to force the legacy behavior should set a default value for the 'mm' parameter in their `solrconfig.xml` file. Users should add this as a configured default for their request handlers. This parameter tolerates miscellaneous white spaces in expressions (e.g., `" 3 < -25% 10 < -3\n", " \n-25%\n ", " \n3\n "`).
-|<<TheDisMaxQueryParser-Thepf_PhraseFields_Parameter,pf>> |Phrase Fields: boosts the score of documents in cases where all of the terms in the q parameter appear in close proximity.
-|<<TheDisMaxQueryParser-Theps_PhraseSlop_Parameter,ps>> |Phrase Slop: specifies the number of positions two terms can be apart in order to match the specified phrase.
-|<<TheDisMaxQueryParser-Theqs_QueryPhraseSlop_Parameter,qs>> |Query Phrase Slop: specifies the number of positions two terms can be apart in order to match the specified phrase. Used specifically with the `qf` parameter.
-|<<TheDisMaxQueryParser-Thetie_TieBreaker_Parameter,tie>> |Tie Breaker: specifies a float value (which should be something much less than 1) to use as tiebreaker in DisMax queries. Default: 0.0
-|<<TheDisMaxQueryParser-Thebq_BoostQuery_Parameter,bq>> |Boost Query: specifies a factor by which a term or phrase should be "boosted" in importance when considering a match.
-|<<TheDisMaxQueryParser-Thebf_BoostFunctions_Parameter,bf>> |Boost Functions: specifies functions to be applied to boosts. (See for details about function queries.)
-|===
+In addition to the common request parameters, highlighting parameters, and simple facet parameters, the DisMax query parser supports the parameters described below. Like the standard query parser, the DisMax query parser allows default parameter values to be specified in `solrconfig.xml`, or overridden by query-time values in the request.
The sections below explain these parameters in detail.
-[[TheDisMaxQueryParser-TheqParameter]]
-=== The q Parameter
+=== q Parameter
The `q` parameter defines the main "query" constituting the essence of the search. The parameter supports raw input strings provided by users with no special escaping. The + and - characters are treated as "mandatory" and "prohibited" modifiers for terms. Text wrapped in balanced quote characters (for example, "San Jose") is treated as a phrase. Any query containing an odd number of quote characters is evaluated as if there were no quote characters at all.
-[IMPORTANT]
-====
-
-The `q` parameter does not support wildcard characters such as *.
+IMPORTANT: The `q` parameter does not support wildcard characters such as *.
-====
-[[TheDisMaxQueryParser-Theq.altParameter]]
-=== The q.alt Parameter
+=== q.alt Parameter
If specified, the `q.alt` parameter defines a query (which by default will be parsed using standard query parsing syntax) when the main q parameter is not specified or is blank. The `q.alt` parameter comes in handy when you need something like a query to match all documents (don't forget `&rows=0` for that one!) in order to get collection-wide faceting counts.
-[[TheDisMaxQueryParser-Theqf_QueryFields_Parameter]]
-=== The qf (Query Fields) Parameter
+=== qf (Query Fields) Parameter
The `qf` parameter introduces a list of fields, each of which is assigned a boost factor to increase or decrease that particular field's importance in the query. For example, the query below:
@@ -85,8 +60,7 @@ The `qf` parameter introduces a list of fields, each of which is assigned a boos
assigns `fieldOne` a boost of 2.3, leaves `fieldTwo` with the default boost (because no boost factor is specified), and `fieldThree` a boost of 0.4. These boost factors make matches in `fieldOne` much more significant than matches in `fieldTwo`, which in turn are much more significant than matches in `fieldThree`.
-[[TheDisMaxQueryParser-Themm_MinimumShouldMatch_Parameter]]
-=== The mm (Minimum Should Match) Parameter
+=== mm (Minimum Should Match) Parameter
When processing queries, Lucene/Solr recognizes three types of clauses: mandatory, prohibited, and "optional" (also known as "should" clauses). By default, all words or phrases specified in the `q` parameter are treated as "optional" clauses unless they are preceded by a "+" or a "-". When dealing with these "optional" clauses, the `mm` parameter makes it possible to say that a certain minimum number of those clauses must match. The DisMax query parser offers great flexibility in how the minimum number can be specified.
@@ -115,27 +89,23 @@ When specifying `mm` values, keep in mind the following:
The default value of `mm` is 100% (meaning that all clauses must match).
-[[TheDisMaxQueryParser-Thepf_PhraseFields_Parameter]]
-=== The pf (Phrase Fields) Parameter
+=== pf (Phrase Fields) Parameter
Once the list of matching documents has been identified using the `fq` and `qf` parameters, the `pf` parameter can be used to "boost" the score of documents in cases where all of the terms in the q parameter appear in close proximity.
The format is the same as that used by the `qf` parameter: a list of fields and "boosts" to associate with each of them when making phrase queries out of the entire q parameter.
-[[TheDisMaxQueryParser-Theps_PhraseSlop_Parameter]]
-=== The ps (Phrase Slop) Parameter
+=== ps (Phrase Slop) Parameter
The `ps` parameter specifies the amount of "phrase slop" to apply to queries specified with the pf parameter. Phrase slop is the number of positions one token needs to be moved in relation to another token in order to match a phrase specified in a query.
-[[TheDisMaxQueryParser-Theqs_QueryPhraseSlop_Parameter]]
-=== The qs (Query Phrase Slop) Parameter
+=== qs (Query Phrase Slop) Parameter
The `qs` parameter specifies the amount of slop permitted on phrase queries explicitly included in the user's query string with the `qf` parameter. As explained above, slop refers to the number of positions one token needs to be moved in relation to another token in order to match a phrase specified in a query.
-[[TheDisMaxQueryParser-Thetie_TieBreaker_Parameter]]
=== The tie (Tie Breaker) Parameter
The `tie` parameter specifies a float value (which should be something much less than 1) to use as tiebreaker in DisMax queries.
@@ -145,8 +115,7 @@ When a term from the user's input is tested against multiple fields, more than o
A value of "0.0" - the default - makes the query a pure "disjunction max query": that is, only the maximum scoring subquery contributes to the final score. A value of "1.0" makes the query a pure "disjunction sum query" where it doesn't matter what the maximum scoring sub query is, because the final score will be the sum of the subquery scores. Typically a low value, such as 0.1, is useful.
-[[TheDisMaxQueryParser-Thebq_BoostQuery_Parameter]]
-=== The bq (Boost Query) Parameter
+=== bq (Boost Query) Parameter
The `bq` parameter specifies an additional, optional, query clause that will be added to the user's main query to influence the score. For example, if you wanted to add a relevancy boost for recent documents:
@@ -159,8 +128,7 @@ bq=date:[NOW/DAY-1YEAR TO NOW/DAY]
You can specify multiple `bq` parameters. If you want your query to be parsed as separate clauses with separate boosts, use multiple `bq` parameters.
-[[TheDisMaxQueryParser-Thebf_BoostFunctions_Parameter]]
-=== The bf (Boost Functions) Parameter
+=== bf (Boost Functions) Parameter
The `bf` parameter specifies functions (with optional boosts) that will be used to construct FunctionQueries which will be added to the user's main query as optional clauses that will influence the score. Any function supported natively by Solr can be used, along with a boost value. For example:
@@ -180,7 +148,7 @@ bf=recip(rord(creationDate),1,1000,1000)
bq={!func}recip(rord(creationDate),1,1000,1000)
----
-[[TheDisMaxQueryParser-ExamplesofQueriesSubmittedtotheDisMaxQueryParser]]
+
== Examples of Queries Submitted to the DisMax Query Parser
All of the sample URLs in this section assume you are running Solr's "techproducts" example:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc b/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
index c4e0fde..3b0bd49 100644
--- a/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
@@ -1,4 +1,4 @@
-= The Extended DisMax Query Parser
+= The Extended DisMax (eDismax) Query Parser
:page-shortname: the-extended-dismax-query-parser
:page-permalink: the-extended-dismax-query-parser.html
// Licensed to the Apache Software Foundation (ASF) under one
@@ -33,76 +33,52 @@ In addition to supporting all the DisMax query parser parameters, Extended Disma
* 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.
-[[TheExtendedDisMaxQueryParser-ExtendedDisMaxParameters]]
== Extended DisMax Parameters
-In addition to all the <<the-dismax-query-parser.adoc#TheDisMaxQueryParser-DisMaxParameters,DisMax parameters>>, Extended DisMax includes these query parameters:
+In addition to all the <<the-dismax-query-parser.adoc#dismax-query-parser-parameters,DisMax parameters>>, Extended DisMax includes these query parameters:
-[[TheExtendedDisMaxQueryParser-ThesowParameter]]
-=== The sow Parameter
+`sow`::
+Split on whitespace. If set to `false`, whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g., multi-word synonyms and shingles. Defaults to `true`, so text analysis is invoked separately for each individual whitespace-separated term.
-Split on whitespace: if set to `false`, whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g. multi-word synonyms and shingles. Defaults to `true`: text analysis is invoked separately for each individual whitespace-separated term.
-
-[[TheExtendedDisMaxQueryParser-Themm.autoRelaxParameter]]
-=== The mm.autoRelax Parameter
-
-If true, the number of clauses required (<<the-dismax-query-parser.adoc#TheDisMaxQueryParser-Themm_MinimumShouldMatch_Parameter,minimum should match>>) will automatically be relaxed if a clause is removed (by e.g. stopwords filter) from some but not all <<the-dismax-query-parser.adoc#TheDisMaxQueryParser-Theqf_QueryFields_Parameter,`qf`>> fields. Use this parameter as a workaround if you experience that queries return zero hits due to uneven stopword removal between the `qf` fields.
-
-Note that relaxing mm may cause undesired side effects, hurting the precision of the search, depending on the nature of your index content.
-
-[[TheExtendedDisMaxQueryParser-TheboostParameter]]
-=== The boost Parameter
-
-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`
+`mm.autoRelax`::
+If `true`, the number of clauses required (<<the-dismax-query-parser.adoc#mm-minimum-should-match-parameter,minimum should match>>) will automatically be relaxed if a clause is removed (by e.g. stopwords filter) from some but not all <<the-dismax-query-parser.adoc#qf-query-fields-parameter,`qf`>> fields. Use this parameter as a workaround if you experience that queries return zero hits due to uneven stopword removal between the `qf` fields.
++
+Note that relaxing `mm` may cause undesired side effects, such as hurting the precision of the search, depending on the nature of your index content.
-[[TheExtendedDisMaxQueryParser-ThelowercaseOperatorsParameter]]
-=== The lowercaseOperators Parameter
+`boost`::
+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`.
+`lowercaseOperators`::
A Boolean parameter indicating if lowercase "and" and "or" should be treated the same as operators "AND" and "OR".
Defaults to `false`.
-[[TheExtendedDisMaxQueryParser-ThepsParameter]]
-=== The ps Parameter
-
-Default amount of slop on phrase queries built with `pf`, `pf2` and/or `pf3` fields (affects boosting).
+`ps`::
+Phrase Slop. The default amount of slop - distance between terms - on phrase queries built with `pf`, `pf2` and/or `pf3` fields (affects boosting). See also the section <<Using 'Slop'>> below.
-[[TheExtendedDisMaxQueryParser-Thepf2Parameter]]
-=== The pf2 Parameter
+`pf2`::
-A multivalued list of fields with optional weights, based on pairs of word shingles.
-
-[[TheExtendedDisMaxQueryParser-Theps2Parameter]]
-=== The ps2 Parameter
+A multivalued list of fields with optional weights. Similar to `pf`, but based on _pairs_ of word shingles.
+`ps2`::
This is similar to `ps` but overrides the slop factor used for `pf2`. If not specified, `ps` is used.
-[[TheExtendedDisMaxQueryParser-Thepf3Parameter]]
-=== The pf3 Parameter
-
-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.
-
-[[TheExtendedDisMaxQueryParser-Theps3Parameter]]
-=== The ps3 Parameter
+`pf3`::
+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.
+`ps3`::
This is similar to `ps` but overrides the slop factor used for `pf3`. If not specified, `ps` is used.
-[[TheExtendedDisMaxQueryParser-ThestopwordsParameter]]
-=== The stopwords Parameter
-
-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.
-
-[[TheExtendedDisMaxQueryParser-TheufParameter]]
-=== The uf Parameter
+`stopwords`::
+A Boolean parameter indicating if the `StopFilterFactory` configured in the query analyzer should be respected when parsing the query. If this is set to `false`, then the `StopFilterFactory` in the query analyzer is ignored.
+`uf`::
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=-*`.
-[[TheExtendedDisMaxQueryParser-Fieldaliasingusingper-fieldqfoverrides]]
-=== Field aliasing using per-field qf overrides
+=== Field Aliasing using Per-Field qf Overrides
Per-field overrides of the `qf` parameter may be specified to provide 1-to-many aliasing from field names specified in the query string, to field names used in the underlying query. By default, no aliasing is used and field names specified in the query string are treated as literal field names in the index.
-[[TheExtendedDisMaxQueryParser-ExamplesofQueriesSubmittedtotheExtendedDisMaxQueryParser]]
-== Examples of Queries Submitted to the Extended DisMax Query Parser
+== Examples of eDismax Queries
All of the sample URLs in this section assume you are running Solr's "```techproducts```" example:
@@ -158,14 +134,12 @@ qf=title text last_name first_name
f.name.qf=last_name first_name
----
-[[TheExtendedDisMaxQueryParser-Usingnegativeboost]]
-== Using negative boost
+== Using Negative Boost
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.
-[[TheExtendedDisMaxQueryParser-Using_slop_]]
-== Using 'slop'
+== Using 'Slop'
`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:
@@ -223,8 +197,7 @@ A document that contains "Hans Anderson" will match, but a document that contain
Finally, in addition to the phrase fields (`pf`) parameter, `edismax` also supports the `pf2` and `pf3` parameters, for fields over which to create bigram and trigram phrase queries. The phrase slop for these parameters' queries can be specified using the `ps2` and `ps3` parameters, respectively. If you use `pf2`/`pf3` but `ps2`/`ps3`, then the phrase slop for these parameters' queries will be taken from the `ps` parameter, if any.
-[[TheExtendedDisMaxQueryParser-Usingthe_magicfields__val_and_query_]]
-== Using the "magic fields" \_val_ and \_query_
+== Using the "Magic Fields" \_val_ and \_query_
The Solr Query Parser's use of `\_val_` and `\_query_` differs from the Lucene Query Parser in the following ways:
@@ -257,9 +230,4 @@ createdate:[1976-03-06T23:59:59.999Z TO 1976-03-06T23:59:59.999Z+1YEAR]
createdate:[1976-03-06T23:59:59.999Z/YEAR TO 1976-03-06T23:59:59.999Z]
----
-[IMPORTANT]
-====
-
-`TO` must be uppercase, or Solr will report a 'Range Group' error.
-
-====
+IMPORTANT: `TO` must be uppercase, or Solr will report a 'Range Group' error.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/the-standard-query-parser.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/the-standard-query-parser.adoc b/solr/solr-ref-guide/src/the-standard-query-parser.adoc
index f389b92..b58c4f3 100644
--- a/solr/solr-ref-guide/src/the-standard-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-standard-query-parser.adoc
@@ -22,31 +22,28 @@ Solr's default Query Parser is also known as the "```lucene```" parser.
The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it's very intolerant of syntax errors, as compared with something like the <<the-dismax-query-parser.adoc#the-dismax-query-parser,DisMax>> query parser which is designed to throw as few errors as possible.
-[[TheStandardQueryParser-StandardQueryParserParameters]]
== Standard Query Parser Parameters
In addition to the <<common-query-parameters.adoc#common-query-parameters,Common Query Parameters>>, <<faceting.adoc#faceting,Faceting Parameters>>, <<highlighting.adoc#highlighting,Highlighting Parameters>>, and <<morelikethis.adoc#morelikethis,MoreLikeThis Parameters>>, the standard query parser supports the parameters described in the table below.
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+`q`::
+Defines a query using standard query syntax. This parameter is mandatory.
-[cols="30,70",options="header"]
-|===
-|Parameter |Description
-|q |Defines a query using standard query syntax. This parameter is mandatory.
-|q.op |Specifies the default operator for query expressions, overriding the default operator specified in the Schema. Possible values are "AND" or "OR".
-|df |Specifies a default field, overriding the definition of a default field in the Schema.
-|sow |Split on whitespace: if set to `false`, whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g. multi-word synonyms and shingles. Defaults to `true`: text analysis is invoked separately for each individual whitespace-separated term.
-|===
+`q.op`::
+Specifies the default operator for query expressions, overriding the default operator specified in the Schema. Possible values are "AND" or "OR".
-Default parameter values are specified in `solrconfig.xml`, or overridden by query-time values in the request.
+`df`::
+Specifies a default field, overriding the definition of a default field in the Schema.
+
+`sow`::
+Split on whitespace: if set to `false`, whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g. multi-word synonyms and shingles. Defaults to `true`: text analysis is invoked separately for each individual whitespace-separated term.
+Default parameter values are specified in `solrconfig.xml`, or overridden by query-time values in the request.
-[[TheStandardQueryParser-TheStandardQueryParser_sResponse]]
-== The Standard Query Parser's Response
+== Standard Query Parser Response
-By default, the response from the standard query parser contains one `<result>` block, which is unnamed. If the <<common-query-parameters.adoc#CommonQueryParameters-ThedebugParameter,`debug` parameter>> is used, then an additional `<lst>` block will be returned, using the name "debug". This will contain useful debugging info, including the original query string, the parsed query string, and explain info for each document in the <result> block. If the <<common-query-parameters.adoc#CommonQueryParameters-TheexplainOtherParameter,`explainOther` parameter>> is also used, then additional explain info will be provided for all the documents matching that query.
+By default, the response from the standard query parser contains one `<result>` block, which is unnamed. If the <<common-query-parameters.adoc#debug-parameter,`debug` parameter>> is used, then an additional `<lst>` block will be returned, using the name "debug". This will contain useful debugging info, including the original query string, the parsed query string, and explain info for each document in the <result> block. If the <<common-query-parameters.adoc#explainother-parameter,`explainOther` parameter>> is also used, then additional explain info will be provided for all the documents matching that query.
-[[TheStandardQueryParser-SampleResponses]]
=== Sample Responses
This section presents examples of responses from the standard query parser.
@@ -97,7 +94,6 @@ Results:
</response>
----
-[[TheStandardQueryParser-SpecifyingTermsfortheStandardQueryParser]]
== Specifying Terms for the Standard Query Parser
A query to the standard query parser is broken up into terms and operators. There are two types of terms: single terms and phrases.
@@ -107,19 +103,12 @@ A query to the standard query parser is broken up into terms and operators. Ther
Multiple terms can be combined together with Boolean operators to form more complex queries (as described below).
-[IMPORTANT]
-====
+IMPORTANT: It is important that the analyzer used for queries parses terms and phrases in a way that is consistent with the way the analyzer used for indexing parses terms and phrases; otherwise, searches may produce unexpected results.
-It is important that the analyzer used for queries parses terms and phrases in a way that is consistent with the way the analyzer used for indexing parses terms and phrases; otherwise, searches may produce unexpected results.
-
-====
-
-[[TheStandardQueryParser-TermModifiers]]
=== Term Modifiers
Solr supports a variety of term modifiers that add flexibility or precision, as needed, to searches. These modifiers include wildcard characters, characters for making a search "fuzzy" or more general, and so on. The sections below describe these modifiers in detail.
-[[TheStandardQueryParser-WildcardSearches]]
=== Wildcard Searches
Solr's standard query parser supports single and multiple character wildcard searches within single terms. Wildcard characters can be applied to single terms, but not to search phrases.
@@ -133,7 +122,6 @@ Solr's standard query parser supports single and multiple character wildcard sea
|Multiple characters (matches zero or more sequential characters) |* |The wildcard search: `tes*` would match test, testing, and tester. You can also use wildcard characters in the middle of a term. For example: `te*t` would match test and text. `*est` would match pest and test.
|===
-[[TheStandardQueryParser-FuzzySearches]]
=== Fuzzy Searches
Solr's standard query parser supports fuzzy searches based on the Damerau-Levenshtein Distance or Edit Distance algorithm. Fuzzy searches discover terms that are similar to a specified term without necessarily being an exact match. To perform a fuzzy search, use the tilde ~ symbol at the end of a single-word term. For example, to search for a term similar in spelling to "roam," use the fuzzy search:
@@ -148,14 +136,8 @@ An optional distance parameter specifies the maximum number of edits allowed, be
This will match terms like roams & foam - but not foams since it has an edit distance of "2".
-[IMPORTANT]
-====
-
-In many cases, stemming (reducing terms to a common stem) can produce similar effects to fuzzy searches and wildcard searches.
+IMPORTANT: In many cases, stemming (reducing terms to a common stem) can produce similar effects to fuzzy searches and wildcard searches.
-====
-
-[[TheStandardQueryParser-ProximitySearches]]
=== Proximity Searches
A proximity search looks for terms that are within a specific distance from one another.
@@ -166,7 +148,6 @@ To perform a proximity search, add the tilde character ~ and a numeric value to
The distance referred to here is the number of term movements needed to match the specified phrase. In the example above, if "apache" and "jakarta" were 10 spaces apart in a field, but "apache" appeared before "jakarta", more than 10 term movements would be required to move the terms together and position "apache" to the right of "jakarta" with a space in between.
-[[TheStandardQueryParser-RangeSearches]]
=== Range Searches
A range search specifies a range of values for a field (a range with an upper bound and a lower bound). The query matches documents whose values for the specified field or fields fall within the range. Range queries can be inclusive or exclusive of the upper and lower bounds. Sorting is done lexicographically, except on numeric fields. For example, the range query below matches all documents whose `popularity` field has a value between 52 and 10,000, inclusive.
@@ -185,8 +166,6 @@ The brackets around a query determine its inclusiveness.
* Curly brackets `{` & `}` denote an exclusive range query that matches values between the upper and lower bounds, but excluding the upper and lower bounds themselves.
* You can mix these types so one end of the range is inclusive and the other is exclusive. Here's an example: `count:{1 TO 10]`
-
-[[TheStandardQueryParser-BoostingaTermwith_]]
=== Boosting a Term with "^"
Lucene/Solr provides the relevance level of matching documents based on the terms found. To boost a term use the caret symbol `^` with a boost factor (a number) at the end of the term you are searching. The higher the boost factor, the more relevant the term will be.
@@ -204,7 +183,6 @@ This will make documents with the term jakarta appear more relevant. You can als
By default, the boost factor is 1. Although the boost factor must be positive, it can be less than 1 (for example, it could be 0.2).
-[[TheStandardQueryParser-ConstantScorewith_]]
=== Constant Score with "^="
Constant score queries are created with `<query_clause>^=<score>`, which sets the entire clause to the specified score for any documents matching that clause. This is desirable when you only care about matches for a particular clause and don't want other relevancy factors such as term frequency (the number of times the term appears in the field) or inverse document frequency (a measure across the whole index for how rare a term is in a field).
@@ -214,9 +192,7 @@ Example:
[source,text]
(description:blue OR color:blue)^=1.0 text:shoes
-
-[[TheStandardQueryParser-SpecifyingFieldsinaQuerytotheStandardQueryParser]]
-== Specifying Fields in a Query to the Standard Query Parser
+== Querying Specific Fields
Data indexed in Solr is organized in fields, which are <<defining-fields.adoc#defining-fields,defined in the Solr Schema>>. Searches can take advantage of fields to add precision to queries. For example, you can search for a term only in a specific field, such as a title field.
@@ -234,7 +210,6 @@ Since text is the default field, the field indicator is not required; hence the
The field is only valid for the term that it directly precedes, so the query `title:Do it right` will find only "Do" in the title field. It will find "it" and "right" in the default field (in this case the text field).
-[[TheStandardQueryParser-BooleanOperatorsSupportedbytheStandardQueryParser]]
== Boolean Operators Supported by the Standard Query Parser
Boolean operators allow you to apply Boolean logic to queries, requiring the presence or absence of specific terms or conditions in fields in order to match documents. The table below summarizes the Boolean operators supported by the standard query parser.
@@ -253,19 +228,9 @@ Boolean operators allow you to apply Boolean logic to queries, requiring the pre
Boolean operators allow terms to be combined through logic operators. Lucene supports AND, "`+`", OR, NOT and "`-`" as Boolean operators.
-[IMPORTANT]
-====
-
-When specifying Boolean operators with keywords such as AND or NOT, the keywords must appear in all uppercase.
-
-====
+IMPORTANT: When specifying Boolean operators with keywords such as AND or NOT, the keywords must appear in all uppercase.
-[NOTE]
-====
-
-The standard query parser supports all the Boolean operators listed in the table above. The DisMax query parser supports only `+` and `-`.
-
-====
+NOTE: The standard query parser supports all the Boolean operators listed in the table above. The DisMax query parser supports only `+` and `-`.
The OR operator is the default conjunction operator. This means that if there is no Boolean operator between two terms, the OR operator is used. The OR operator links two terms and finds a matching document if either of the terms exist in a document. This is equivalent to a union using sets. The symbol || can be used in place of the word OR.
@@ -277,8 +242,6 @@ or
`"jakarta apache" OR jakarta`
-
-[[TheStandardQueryParser-TheBooleanOperator_]]
=== The Boolean Operator "+"
The `+` symbol (also known as the "required" operator) requires that the term after the `+` symbol exist somewhere in a field in at least one document in order for the query to return a match.
@@ -287,15 +250,8 @@ For example, to search for documents that must contain "jakarta" and that may or
`+jakarta lucene`
-[NOTE]
-====
+NOTE: This operator is supported by both the standard query parser and the DisMax query parser.
-This operator is supported by both the standard query parser and the DisMax query parser.
-
-====
-
-
-[[TheStandardQueryParser-TheBooleanOperatorAND_]]
=== The Boolean Operator AND ("&&")
The AND operator matches documents where both terms exist anywhere in the text of a single document. This is equivalent to an intersection using sets. The symbol `&&` can be used in place of the word AND.
@@ -307,7 +263,6 @@ To search for documents that contain "jakarta apache" and "Apache Lucene," use e
`"jakarta apache" && "Apache Lucene"`
-[[TheStandardQueryParser-TheBooleanOperatorNOT_]]
=== The Boolean Operator NOT ("!")
The NOT operator excludes documents that contain the term after NOT. This is equivalent to a difference using sets. The symbol `!` can be used in place of the word NOT.
@@ -318,7 +273,6 @@ The following queries search for documents that contain the phrase "jakarta apac
`"jakarta apache" ! "Apache Lucene"`
-[[TheStandardQueryParser-TheBooleanOperator-]]
=== The Boolean Operator "-"
The `-` symbol or "prohibit" operator excludes documents that contain the term after the `-` symbol.
@@ -327,7 +281,6 @@ For example, to search for documents that contain "jakarta apache" but not "Apac
`"jakarta apache" -"Apache Lucene"`
-[[TheStandardQueryParser-EscapingSpecialCharacters]]
=== Escaping Special Characters
Solr gives the following characters special meaning when they appear in a query:
@@ -341,7 +294,6 @@ To make Solr interpret any of these characters literally, rather as a special ch
\(1\+1\)\:2
----
-[[TheStandardQueryParser-GroupingTermstoFormSub-Queries]]
== Grouping Terms to Form Sub-Queries
Lucene/Solr supports using parentheses to group clauses to form sub-queries. This can be very useful if you want to control the Boolean logic for a query.
@@ -352,15 +304,13 @@ The query below searches for either "jakarta" or "apache" and "website":
This adds precision to the query, requiring that the term "website" exist, along with either term "jakarta" and "apache."
-[[TheStandardQueryParser-GroupingClauseswithinaField]]
=== Grouping Clauses within a Field
To apply two or more Boolean operators to a single field in a search, group the Boolean clauses within parentheses. For example, the query below searches for a title field that contains both the word "return" and the phrase "pink panther":
`title:(+return +"pink panther")`
-[[TheStandardQueryParser-Comments]]
-== Comments
+== Comments in Queries
C-Style comments are supported in query strings.
@@ -370,7 +320,6 @@ Example:
Comments may be nested.
-[[TheStandardQueryParser-DifferencesbetweenLuceneQueryParserandtheSolrStandardQueryParser]]
== Differences between Lucene Query Parser and the Solr Standard Query Parser
Solr's standard query parser differs from the Lucene Query Parser in the following ways:
@@ -399,7 +348,6 @@ This can even be used to cache individual clauses of complex filter queries. In
* Constant score queries are created with `<query_clause>^=<score>`, which sets the entire clause to the specified score for any documents matching that clause:
** `q=(description:blue color:blue)^=1.0 title:blue^=5.0`
-[[TheStandardQueryParser-SpecifyingDatesandTimes]]
=== Specifying Dates and Times
Queries against fields using the `TrieDateField` type (typically range queries) should use the <<working-with-dates.adoc#working-with-dates,appropriate date syntax>>:
@@ -410,9 +358,3 @@ Queries against fields using the `TrieDateField` type (typically range queries)
* `pubdate:[NOW-1YEAR/DAY TO NOW/DAY+1DAY]`
* `createdate:[1976-03-06T23:59:59.999Z TO 1976-03-06T23:59:59.999Z+1YEAR]`
* `createdate:[1976-03-06T23:59:59.999Z/YEAR TO 1976-03-06T23:59:59.999Z]`
-
-[[TheStandardQueryParser-RelatedTopics]]
-== Related Topics
-
-* <<local-parameters-in-queries.adoc#local-parameters-in-queries,Local Parameters in Queries>>
-* <<other-parsers.adoc#other-parsers,Other Parsers>>
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/the-stats-component.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/the-stats-component.adoc b/solr/solr-ref-guide/src/the-stats-component.adoc
index ada56a8..b354505 100644
--- a/solr/solr-ref-guide/src/the-stats-component.adoc
+++ b/solr/solr-ref-guide/src/the-stats-component.adoc
@@ -192,4 +192,4 @@ Here we compute some statistics for the price field. The min, max, mean, 90th, a
Sets of `stats.field` parameters can be referenced by `'tag'` when using Pivot Faceting to compute multiple statistics at every level (i.e.: field) in the tree of pivot constraints.
-For more information and a detailed example, please see <<faceting.adoc#Faceting-CombiningStatsComponentWithPivots,Combining Stats Component With Pivots>>.
+For more information and a detailed example, please see <<faceting.adoc#combining-stats-component-with-pivots,Combining Stats Component With Pivots>>.