You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2017/07/14 21:35:09 UTC
[2/2] lucene-solr:master: SOLR-11050,
SOLR-10892: last set of Confluence-style anchors removed and
parameter tables obliterated
SOLR-11050, SOLR-10892: last set of Confluence-style anchors removed and parameter tables obliterated
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/bbae31b9
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/bbae31b9
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/bbae31b9
Branch: refs/heads/master
Commit: bbae31b9d22d0f96810edbbe8898bb3016f0c253
Parents: 4cb74a5
Author: Cassandra Targett <ct...@apache.org>
Authored: Fri Jul 14 16:33:50 2017 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri Jul 14 16:35:01 2017 -0500
----------------------------------------------------------------------
.../src/collapse-and-expand-results.adoc | 2 +-
.../src/common-query-parameters.adoc | 143 +++----
.../solr-ref-guide/src/configuring-logging.adoc | 2 +-
solr/solr-ref-guide/src/defining-fields.adoc | 2 +-
solr/solr-ref-guide/src/docvalues.adoc | 6 +-
solr/solr-ref-guide/src/faceting.adoc | 390 ++++++-------------
.../field-type-definitions-and-properties.adoc | 6 +-
solr/solr-ref-guide/src/function-queries.adoc | 2 +-
.../src/indexconfig-in-solrconfig.adoc | 2 +-
solr/solr-ref-guide/src/query-re-ranking.adoc | 2 +-
solr/solr-ref-guide/src/realtime-get.adoc | 2 +-
...lers-and-searchcomponents-in-solrconfig.adoc | 4 +-
solr/solr-ref-guide/src/spell-checking.adoc | 190 +++------
.../src/the-dismax-query-parser.adoc | 58 +--
.../src/the-extended-dismax-query-parser.adoc | 88 ++---
.../src/the-standard-query-parser.adoc | 96 +----
.../solr-ref-guide/src/the-stats-component.adoc | 2 +-
17 files changed, 307 insertions(+), 690 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
index 0c0bbd1..3a99897 100644
--- a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
+++ b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
@@ -44,7 +44,7 @@ At most only one of the `min`, `max`, or `sort` (see below) parameters may be sp
If none are specified, the group head document of each group will be selected based on the highest scoring document in that group. The default is none.
sort::
-Selects the group head document for each group based on which document comes first according to the specified <<common-query-parameters.adoc#CommonQueryParameters-ThesortParameter,sort string>>.
+Selects the group head document for each group based on which document comes first according to the specified <<common-query-parameters.adoc#sort-parameter,sort string>>.
+
At most only one of the `min`, `max`, (see above) or `sort` parameters may be specified.
+
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/common-query-parameters.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
index 1eea080..08ce788 100644
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -20,33 +20,9 @@
Several query parsers share supported query parameters.
-The table below summarizes Solr's common query parameters, which are supported by the <<requesthandlers-and-searchcomponents-in-solrconfig#searchhandlers,Search RequestHandlers>>
+The following sections describe Solr's common query parameters, which are supported by the <<requesthandlers-and-searchcomponents-in-solrconfig#searchhandlers,Search RequestHandlers>>.
-// 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
-|<<CommonQueryParameters-ThedefTypeParameter,defType>> |Selects the query parser to be used to process the query.
-|<<CommonQueryParameters-ThesortParameter,sort>> |Sorts the response to a query in either ascending or descending order based on the response's score or another specified characteristic.
-|<<CommonQueryParameters-ThestartParameter,start>> |Specifies an offset (by default, 0) into the responses at which Solr should begin displaying content.
-|<<CommonQueryParameters-TherowsParameter,rows>> |Controls how many rows of responses are displayed at a time (default value: 10)
-|<<CommonQueryParameters-Thefq_FilterQuery_Parameter,fq>> |Applies a filter query to the search results.
-|<<CommonQueryParameters-Thefl_FieldList_Parameter,fl>> |Limits the information included in a query response to a specified list of fields. The fields need to either be `stored="true"` or `docValues="true"`
-|<<CommonQueryParameters-ThedebugParameter,debug>> |Request additional debugging information in the response. Specifying the `debug=timing` parameter returns just the timing information; specifying the `debug=results` parameter returns "explain" information for each of the documents returned; specifying the `debug=query parameter` returns all of the debug information.
-|<<CommonQueryParameters-TheexplainOtherParameter,explainOther>> |Allows clients to specify a Lucene query to identify a set of documents. If non-blank, the explain info of each document which matches this query, relative to the main query (specified by the q parameter) will be returned along with the rest of the debugging information.
-|<<CommonQueryParameters-ThetimeAllowedParameter,timeAllowed>> |Defines the time allowed for the query to be processed. If the time elapses before the query response is complete, partial information may be returned.
-|<<CommonQueryParameters-ThesegmentTerminateEarlyParameter,segmentTerminateEarly>> |Indicates that, if possible, Solr should stop collecting documents from each individual (sorted) segment once it can determine that any subsequent documents in that segment will not be candidates for the `rows` being returned. The default is false.
-|<<CommonQueryParameters-TheomitHeaderParameter,omitHeader>> |Excludes the header from the returned results, if set to true. The header contains information about the request, such as the time the request took to complete. The default is false.
-|<<CommonQueryParameters-ThewtParameter,wt>> |Specifies the Response Writer to be used to format the query response.
-|<<CommonQueryParameters-ThelogParamsListParameter,logParamsList>> |By default, Solr logs all parameters. Set this parameter to restrict which parameters are logged. Valid entries are the parameters to be logged, separated by commas (i.e., `logParamsList=param1,param2`). An empty list will log no parameters, so if logging all parameters is desired, do not define this additional parameter at all.
-|<<CommonQueryParameters-TheechoParamsParameter,echoParams>> |The response header can include parameters sent with the query request. This parameter controls what is contained in that section of the response header. Valid values are `none`, `all`, and `explicit`. The default value is `explicit.`
-|===
-
-The following sections describe these parameters in detail.
-
-[[CommonQueryParameters-ThedefTypeParameter]]
-== The defType Parameter
+== defType Parameter
The defType parameter selects the query parser that Solr should use to process the main query parameter (`q`) in the request. For example:
@@ -54,8 +30,7 @@ The defType parameter selects the query parser that Solr should use to process t
If no defType param is specified, then by default, the <<the-standard-query-parser.adoc#the-standard-query-parser,The Standard Query Parser>> is used. (eg: `defType=lucene`)
-[[CommonQueryParameters-ThesortParameter]]
-== The sort Parameter
+== sort Parameter
The `sort` parameter arranges search results in either ascending (`asc`) or descending (`desc`) order. The parameter can be used with either numerical or alphabetical content. The directions can be entered in either all lowercase or all uppercase letters (i.e., both `asc` or `ASC`).
@@ -87,26 +62,23 @@ Regarding the sort parameter's arguments:
* Multiple sort orderings can be separated by a comma, using this syntax: `sort=<field name>+<direction>,<field name>+<direction>],...`
** When more than one sort criteria is provided, the second entry will only be used if the first entry results in a tie. If there is a third entry, it will only be used if the first AND second entries are tied. This pattern continues with further entries.
-[[CommonQueryParameters-ThestartParameter]]
-== The start Parameter
+== start Parameter
When specified, the `start` parameter specifies an offset into a query's result set and instructs Solr to begin displaying results from this offset.
-The default value is "0". In other words, by default, Solr returns results without an offset, beginning where the results themselves begin.
+The default value is `0`. In other words, by default, Solr returns results without an offset, beginning where the results themselves begin.
-Setting the `start` parameter to some other number, such as 3, causes Solr to skip over the preceding records and start at the document identified by the offset.
+Setting the `start` parameter to some other number, such as `3`, causes Solr to skip over the preceding records and start at the document identified by the offset.
You can use the `start` parameter this way for paging. For example, if the `rows` parameter is set to 10, you could display three successive pages of results by setting start to 0, then re-issuing the same query and setting start to 10, then issuing the query again and setting start to 20.
-[[CommonQueryParameters-TherowsParameter]]
-== The rows Parameter
+== rows Parameter
-You can use the rows parameter to paginate results from a query. The parameter specifies the maximum number of documents from the complete result set that Solr should return to the client at one time.
+You can use the `rows` parameter to paginate results from a query. The parameter specifies the maximum number of documents from the complete result set that Solr should return to the client at one time.
-The default value is 10. That is, by default, Solr returns 10 documents at a time in response to a query.
+The default value is `10`. That is, by default, Solr returns 10 documents at a time in response to a query.
-[[CommonQueryParameters-Thefq_FilterQuery_Parameter]]
-== The fq (Filter Query) Parameter
+== fq (Filter Query) Parameter
The `fq` parameter defines a query that can be used to restrict the superset of documents that can be returned, without influencing score. It can be very useful for speeding up complex queries, since the queries specified with `fq` are cached independently of the main query. When a later query uses the same filter, there's a cache hit, and filter results are returned quickly from the cache.
@@ -127,14 +99,13 @@ fq=+popularity:[10 TO *] +section:0
----
* The document sets from each filter query are cached independently. Thus, concerning the previous examples: use a single `fq` containing two mandatory clauses if those clauses appear together often, and use two separate `fq` parameters if they are relatively independent. (To learn about tuning cache sizes and making sure a filter cache actually exists, see <<the-well-configured-solr-instance.adoc#the-well-configured-solr-instance,The Well-Configured Solr Instance>>.)
-* It is also possible to use <<the-standard-query-parser.adoc#TheStandardQueryParser-DifferencesbetweenLuceneQueryParserandtheSolrStandardQueryParser,filter(condition) syntax>> inside the `fq` to cache clauses individually and - among other things - to achieve union of cached filter queries.
+* It is also possible to use <<the-standard-query-parser.adoc#differences-between-lucene-query-parser-and-the-solr-standard-query-parser,filter(condition) syntax>> inside the `fq` to cache clauses individually and - among other things - to achieve union of cached filter queries.
* As with all parameters: special characters in an URL need to be properly escaped and encoded as hex values. Online tools are available to help you with URL-encoding. For example: http://meyerweb.com/eric/tools/dencoder/.
-[[CommonQueryParameters-Thefl_FieldList_Parameter]]
-== The fl (Field List) Parameter
+== fl (Field List) Parameter
-The `fl` parameter limits the information included in a query response to a specified list of fields. The fields need to either be `stored="true"` or `docValues="true"``.`
+The `fl` parameter limits the information included in a query response to a specified list of fields. The fields must be either `stored="true"` or `docValues="true"``.`
The field list can be specified as a space-separated or comma-separated list of field names. The string "score" can be used to indicate that the score of each document for the particular query should be returned as a field. The wildcard character `*` selects all the fields in the document which are either `stored="true"` or `docValues="true"` and `useDocValuesAsStored="true"` (which is the default when docValues are enabled). You can also add pseudo-fields, functions and transformers to the field list request.
@@ -154,8 +125,7 @@ This table shows some basic examples of how to use `fl`:
|*,dv_field_name |Return all the `stored` fields in each document, and any `docValues` fields that have `useDocValuesAsStored="true`" and the docValues from dv_field_name even if it has `useDocValuesAsStored="false`"
|===
-[[CommonQueryParameters-FunctionValues]]
-=== Function Values
+=== Functions with fl
<<function-queries.adoc#function-queries,Functions>> can be computed for each document in the result and returned as a pseudo-field:
@@ -164,8 +134,7 @@ This table shows some basic examples of how to use `fl`:
fl=id,title,product(price,popularity)
----
-[[CommonQueryParameters-DocumentTransformers]]
-=== Document Transformers
+=== Document Transformers with fl
<<transforming-result-documents.adoc#transforming-result-documents,Document Transformers>> can be used to modify the information returned about each documents in the results of a query:
@@ -174,7 +143,6 @@ fl=id,title,product(price,popularity)
fl=id,title,[explain]
----
-[[CommonQueryParameters-FieldNameAliases]]
=== Field Name Aliases
You can change the key used to in the response for a field, function, or transformer by prefixing it with a `_"displayName_:`". For example:
@@ -203,8 +171,7 @@ fl=id,sales_price:price,secret_sauce:prod(price,popularity),why_score:[explain s
}]}}]}}
----
-[[CommonQueryParameters-ThedebugParameter]]
-== The debug Parameter
+== debug Parameter
The `debug` parameter can be specified multiple times and supports the following arguments:
@@ -218,8 +185,7 @@ For backwards compatibility with older versions of Solr, `debugQuery=true` may i
The default behavior is not to include debugging information.
-[[CommonQueryParameters-TheexplainOtherParameter]]
-== The explainOther Parameter
+== explainOther Parameter
The `explainOther` parameter specifies a Lucene query in order to identify a set of documents. If this parameter is included and is set to a non-blank value, the query will return debugging information, along with the "explain info" of each document that matches the Lucene query, relative to the main query (which is specified by the q parameter). For example:
@@ -232,45 +198,40 @@ The query above allows you to examine the scoring explain info of the top matchi
The default value of this parameter is blank, which causes no extra "explain info" to be returned.
-[[CommonQueryParameters-ThetimeAllowedParameter]]
-== The timeAllowed Parameter
+== timeAllowed Parameter
This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <<faceting.adoc#faceting,facet>> counts, and result <<the-stats-component.adoc#the-stats-component,stats>> may not be accurate for the entire result set.
This value is only checked at the time of:
-1. Query Expansion, and
-2. Document collection
+. Query Expansion, and
+. Document collection
-As this check is periodically performed, the actual time for which a request can be processed before it is aborted would be marginally greater than or equal to the value of `timeAllowed`. If the request consumes more time in other stages, e.g., custom components, etc., this parameter is not expected to abort the request.
+As this check is periodically performed, the actual time for which a request can be processed before it is aborted would be marginally greater than or equal to the value of `timeAllowed`. If the request consumes more time in other stages, custom components, etc., this parameter is not expected to abort the request.
-[[CommonQueryParameters-ThesegmentTerminateEarlyParameter]]
-== The segmentTerminateEarly Parameter
+== segmentTerminateEarly Parameter
-This parameter may be set to either true or false.
+This parameter may be set to either `true` or `false`.
-If set to true, and if <<indexconfig-in-solrconfig.adoc#mergepolicyfactory,the mergePolicyFactory>> for this collection is a {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] which uses a `sort` option which is compatible with <<CommonQueryParameters-ThesortParameter,the sort parameter>> specified for this query, then Solr will attempt to use an {lucene-javadocs}/core/org/apache/lucene/search/EarlyTerminatingSortingCollector.html[`EarlyTerminatingSortingCollector`].
+If set to `true`, and if <<indexconfig-in-solrconfig.adoc#mergepolicyfactory,the mergePolicyFactory>> for this collection is a {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] which uses a `sort` option compatible with <<sort Parameter,the sort parameter>> specified for this query, then Solr will attempt to use an {lucene-javadocs}/core/org/apache/lucene/search/EarlyTerminatingSortingCollector.html[`EarlyTerminatingSortingCollector`].
If early termination is used, a `segmentTerminatedEarly` header will be included in the `responseHeader`.
-Similar to using <<CommonQueryParameters-ThetimeAllowedParameter,the `timeAllowed `Parameter>>, when early segment termination happens values such as `numFound`, <<faceting.adoc#faceting,Facet>> counts, and result <<the-stats-component.adoc#the-stats-component,Stats>> may not be accurate for the entire result set.
+Similar to using <<timeAllowed Parameter,the `timeAllowed `Parameter>>, when early segment termination happens values such as `numFound`, <<faceting.adoc#faceting,Facet>> counts, and result <<the-stats-component.adoc#the-stats-component,Stats>> may not be accurate for the entire result set.
-The default value of this parameter is false.
+The default value of this parameter is `false`.
-[[CommonQueryParameters-TheomitHeaderParameter]]
-== The omitHeader Parameter
+== omitHeader Parameter
-This parameter may be set to either true or false.
+This parameter may be set to either `true` or `false`.
-If set to true, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is false.
+If set to `true`, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is `false`.
-[[CommonQueryParameters-ThewtParameter]]
-== The wt Parameter
+== wt Parameter
The `wt` parameter selects the Response Writer that Solr should use to format the query's response. For detailed descriptions of Response Writers, see <<response-writers.adoc#response-writers,Response Writers>>.
-[[CommonQueryParameters-Thecache_falseParameter]]
-== The cache=false Parameter
+== cache Parameter
Solr caches the results of all queries and filter queries by default. To disable result caching, set the `cache=false` parameter.
@@ -279,24 +240,22 @@ You can also use the `cost` option to control the order in which non-cached filt
For very high cost filters, if `cache=false` and `cost>=100` and the query implements the `PostFilter` interface, a Collector will be requested from that query and used to filter documents after they have matched the main query and all other filter queries. There can be multiple post filters; they are also ordered by cost.
For example:
-// TODO: fix this, it looks horrible (CT)
+
+This is a normal function range query used as a filter, all matching documents generated up front and cached:
[source,text]
-----
-// normal function range query used as a filter, all matching documents
-// generated up front and cached
fq={!frange l=10 u=100}mul(popularity,price)
-// function range query run in parallel with the main query like a traditional
-// lucene filter
+This is a function range query run in parallel with the main query like a traditional lucene filter:
+
+[source,text]
fq={!frange l=10 u=100 cache=false}mul(popularity,price)
-// function range query checked after each document that already matches the query
-// and all other filters. Good for really expensive function queries.
+This is a function range query checked after each document that already matches the query and all other filters. This is good for really expensive function queries:
+
+[source,text]
fq={!frange l=10 u=100 cache=false cost=100}mul(popularity,price)
-----
-[[CommonQueryParameters-ThelogParamsListParameter]]
-== The logParamsList Parameter
+== logParamsList Parameter
By default, Solr logs all parameters of requests. Set this parameter to restrict which parameters of a request are logged. This may help control logging to only those parameters considered important to your organization.
@@ -308,27 +267,17 @@ And only the 'q' and 'fq' parameters will be logged.
If no parameters should be logged, you can send `logParamsList` as empty (i.e., `logParamsList=`).
-[TIP]
-====
-This parameter does not only apply to query requests, but to any kind of request to Solr.
-====
+TIP: This parameter not only applies to query requests, but to any kind of request to Solr.
-[[CommonQueryParameters-TheechoParamsParameter]]
-== The echoParams Parameter
+== echoParams Parameter
The `echoParams` parameter controls what information about request parameters is included in the response header.
-The table explains how Solr responds to various settings of the `echoParams` parameter:
+The `echoParams` parameter accepts the following values:
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
-
-[cols="30,70",options="header"]
-|===
-|Value |Meaning
-|explicit |This is the default value. Only parameters included in the actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) will be added to the params section of the response header.
-|all |Include all request parameters that contributed to the query. This will include everything defined in the request handler definition found in `solrconfig.xml` as well as parameters included with the request, plus the `_` parameter. If a parameter is included in the request handler definition AND the request, it will appear multiple times in the response header.
-|none |Entirely removes the "params" section of the response header. No information about the request parameters will be available in the response.
-|===
+* `explicit`: This is the default value. Only parameters included in the actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) will be added to the params section of the response header.
+* `all`: Include all request parameters that contributed to the query. This will include everything defined in the request handler definition found in `solrconfig.xml` as well as parameters included with the request, plus the `_` parameter. If a parameter is included in the request handler definition AND the request, it will appear multiple times in the response header.
+* `none`: Entirely removes the "params" section of the response header. No information about the request parameters will be available in the response.
Here is an example of a JSON response where the echoParams parameter was not included, so the default of `explicit` is active. The request URL that created this response included three parameters - `q`, `wt`, and `indent`:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/configuring-logging.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configuring-logging.adoc b/solr/solr-ref-guide/src/configuring-logging.adoc
index 05a6c74..f1ceb4b 100644
--- a/solr/solr-ref-guide/src/configuring-logging.adoc
+++ b/solr/solr-ref-guide/src/configuring-logging.adoc
@@ -22,7 +22,7 @@ Solr logs are a key way to know what's happening in the system. There are severa
[IMPORTANT]
====
-In addition to the logging options described below, there is a way to configure which request parameters (such as parameters sent as part of queries) are logged with an additional request parameter called `logParamsList`. See the section on <<common-query-parameters.adoc#CommonQueryParameters-ThelogParamsListParameter,Common Query Parameters>> for more information.
+In addition to the logging options described below, there is a way to configure which request parameters (such as parameters sent as part of queries) are logged with an additional request parameter called `logParamsList`. See the section on <<common-query-parameters.adoc#logparamslist-parameter,Common Query Parameters>> for more information.
====
== Temporary Logging Settings
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/defining-fields.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/defining-fields.adoc b/solr/solr-ref-guide/src/defining-fields.adoc
index ef93d60..82f0345 100644
--- a/solr/solr-ref-guide/src/defining-fields.adoc
+++ b/solr/solr-ref-guide/src/defining-fields.adoc
@@ -63,7 +63,7 @@ Fields can have many of the same properties as field types. Properties from the
|omitPositions |Similar to `omitTermFreqAndPositions` but preserves term frequency information. |true or false |*
|termVectors termPositions termOffsets termPayloads |These options instruct Solr to maintain full term vectors for each document, optionally including position, offset and payload information for each term occurrence in those vectors. These can be used to accelerate highlighting and other ancillary functionality, but impose a substantial cost in terms of index size. They are not necessary for typical uses of Solr. |true or false |false
|required |Instructs Solr to reject any attempts to add a document which does not have a value for this field. This property defaults to false. |true or false |false
-|useDocValuesAsStored |If the field has `<<docvalues.adoc#docvalues,docValues>>` enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <<common-query-parameters.adoc#CommonQueryParameters-Thefl_FieldList_Parameter,fl parameter>>. |true or false |true
+|useDocValuesAsStored |If the field has `<<docvalues.adoc#docvalues,docValues>>` enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <<common-query-parameters.adoc#fl-field-list-parameter,fl parameter>>. |true or false |true
|large |Large fields are always lazy loaded and will only take up space in the document cache if the actual value is < 512KB. This option requires `stored="true"` and `multiValued="false"`. It's intended for fields that might have very large values so that they don't get cached in memory. |true or false |false
|===
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/docvalues.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/docvalues.adoc b/solr/solr-ref-guide/src/docvalues.adoc
index 2ec3677..c0b7c31 100644
--- a/solr/solr-ref-guide/src/docvalues.adoc
+++ b/solr/solr-ref-guide/src/docvalues.adoc
@@ -57,7 +57,7 @@ DocValues are only available for specific field types. The types chosen determin
These Lucene types are related to how the {lucene-javadocs}/core/org/apache/lucene/index/DocValuesType.html[values are sorted and stored].
-There is an additional configuration option available, which is to modify the `docValuesFormat` <<field-type-definitions-and-properties.adoc#FieldTypeDefinitionsandProperties-docValuesFormat,used by the field type>>. The default implementation employs a mixture of loading some things into memory and keeping some on disk. In some cases, however, you may choose to specify an alternative {lucene-javadocs}/core/org/apache/lucene/codecs/DocValuesFormat.html[DocValuesFormat implementation]. For example, you could choose to keep everything in memory by specifying `docValuesFormat="Memory"` on a field type:
+There is an additional configuration option available, which is to modify the `docValuesFormat` <<field-type-definitions-and-properties.adoc#docvaluesformat,used by the field type>>. The default implementation employs a mixture of loading some things into memory and keeping some on disk. In some cases, however, you may choose to specify an alternative {lucene-javadocs}/core/org/apache/lucene/codecs/DocValuesFormat.html[DocValuesFormat implementation]. For example, you could choose to keep everything in memory by specifying `docValuesFormat="Memory"` on a field type:
[source,xml]
----
@@ -73,13 +73,13 @@ Lucene index back-compatibility is only supported for the default codec. If you
=== Sorting, Faceting & Functions
-If `docValues="true"` for a field, then DocValues will automatically be used any time the field is used for <<common-query-parameters.adoc#CommonQueryParameters-ThesortParameter,sorting>>, <<faceting.adoc#faceting,faceting>> or <<function-queries.adoc#function-queries,function queries>>.
+If `docValues="true"` for a field, then DocValues will automatically be used any time the field is used for <<common-query-parameters.adoc#sort-parameter,sorting>>, <<faceting.adoc#faceting,faceting>> or <<function-queries.adoc#function-queries,function queries>>.
=== Retrieving DocValues During Search
Field values retrieved during search queries are typically returned from stored values. However, non-stored docValues fields will be also returned along with other stored fields when all fields (or pattern matching globs) are specified to be returned (e.g. "`fl=*`") for search queries depending on the effective value of the `useDocValuesAsStored` parameter for each field. For schema versions >= 1.6, the implicit default is `useDocValuesAsStored="true"`. See <<field-type-definitions-and-properties.adoc#field-type-definitions-and-properties,Field Type Definitions and Properties>> & <<defining-fields.adoc#defining-fields,Defining Fields>> for more details.
-When `useDocValuesAsStored="false"`, non-stored DocValues fields can still be explicitly requested by name in the <<common-query-parameters.adoc#CommonQueryParameters-Thefl_FieldList_Parameter,fl param>>, but will not match glob patterns (`"*"`). Note that returning DocValues along with "regular" stored fields at query time has performance implications that stored fields may not because DocValues are column-oriented and may therefore incur additional cost to retrieve for each returned document. Also note that while returning non-stored fields from DocValues, the values of a multi-valued field are returned in sorted order (and not insertion order). If you require the multi-valued fields to be returned in the original insertion order, then make your multi-valued field as stored (such a change requires re-indexing).
+When `useDocValuesAsStored="false"`, non-stored DocValues fields can still be explicitly requested by name in the <<common-query-parameters.adoc#fl-field-list-parameter,fl param>>, but will not match glob patterns (`"*"`). Note that returning DocValues along with "regular" stored fields at query time has performance implications that stored fields may not because DocValues are column-oriented and may therefore incur additional cost to retrieve for each returned document. Also note that while returning non-stored fields from DocValues, the values of a multi-valued field are returned in sorted order (and not insertion order). If you require the multi-valued fields to be returned in the original insertion order, then make your multi-valued field as stored (such a change requires re-indexing).
In cases where the query is returning _only_ docValues fields performance may improve since returning stored fields requires disk reads and decompression whereas returning docValues fields in the fl list only requires memory access.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/faceting.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/faceting.adoc b/solr/solr-ref-guide/src/faceting.adoc
index 4384a74..bf23e08 100644
--- a/solr/solr-ref-guide/src/faceting.adoc
+++ b/solr/solr-ref-guide/src/faceting.adoc
@@ -23,30 +23,24 @@ Faceting is the arrangement of search results into categories based on indexed t
Searchers are presented with the indexed terms, along with numerical counts of how many matching documents were found for each term. Faceting makes it easy for users to explore search results, narrowing in on exactly the results they are looking for.
-[[Faceting-GeneralParameters]]
-== General Parameters
+== General Facet Parameters
There are two general parameters for controlling faceting.
-[[Faceting-ThefacetParameter]]
-=== The facet Parameter
-
-If set to *true*, this parameter enables facet counts in the query response. If set to *false*, a blank or missing value, this parameter disables faceting. None of the other parameters listed below will have any effect unless this parameter is set to *true*. The default value is blank (false).
-
-[[Faceting-Thefacet.queryParameter]]
-=== The facet.query Parameter
+`facet`::
+If set to `true`, this parameter enables facet counts in the query response. If set to `false`, a blank or missing value, this parameter disables faceting. None of the other parameters listed below will have any effect unless this parameter is set to `true`. The default value is blank (false).
+`facet.query`::
This parameter allows you to specify an arbitrary query in the Lucene default syntax to generate a facet count.
-
++
By default, Solr's faceting feature automatically determines the unique terms for a field and returns a count for each of those terms. Using `facet.query`, you can override this default behavior and select exactly which terms or expressions you would like to see counted. In a typical implementation of faceting, you will specify a number of `facet.query` parameters. This parameter can be particularly useful for numeric-range-based facets or prefix-based facets.
-
++
You can set the `facet.query` parameter multiple times to indicate that multiple queries should be used as separate facet constraints.
-
++
To use facet queries in a syntax other than the default syntax, prefix the facet query with the name of the query notation. For example, to use the hypothetical `myfunc` query parser, you could set the `facet.query` parameter like so:
-
++
`facet.query={!myfunc}name~fred`
-[[Faceting-Field-ValueFacetingParameters]]
== Field-Value Faceting Parameters
Several parameters can be used to trigger faceting based on the indexed terms in a field.
@@ -55,335 +49,218 @@ When using these parameters, it is important to remember that "term" is a very s
If you want Solr to perform both analysis (for searching) and faceting on the full literal strings, use the `copyField` directive in your Schema to create two versions of the field: one Text and one String. Make sure both are `indexed="true"`. (For more information about the `copyField` directive, see <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,Documents, Fields, and Schema Design>>.)
-The table below summarizes Solr's field value faceting parameters.
-
-// 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
-|<<Faceting-Thefacet.fieldParameter,facet.field>> |Identifies a field to be treated as a facet.
-|<<Faceting-Thefacet.prefixParameter,facet.prefix>> |Limits the terms used for faceting to those that begin with the specified prefix.
-|<<Faceting-Thefacet.containsParameter,facet.contains>> |Limits the terms used for faceting to those that contain the specified substring.
-|<<Faceting-Thefacet.contains.ignoreCaseParameter,facet.contains.ignoreCase>> |If facet.contains is used, ignore case when searching for the specified substring.
-|<<Faceting-Thefacet.sortParameter,facet.sort>> |Controls how faceted results are sorted.
-|<<Faceting-Thefacet.limitParameter,facet.limit>> |Controls how many constraints should be returned for each facet.
-|<<Faceting-Thefacet.offsetParameter,facet.offset>> |Specifies an offset into the facet results at which to begin displaying facets.
-|<<Faceting-Thefacet.mincountParameter,facet.mincount>> |Specifies the minimum counts required for a facet field to be included in the response.
-|<<Faceting-Thefacet.missingParameter,facet.missing>> |Controls whether Solr should compute a count of all matching results which have no value for the field, in addition to the term-based constraints of a facet field.
-|<<Faceting-Thefacet.methodParameter,facet.method>> |Selects the algorithm or method Solr should use when faceting a field.
-|<<Faceting-Thefacet.existsParameter,facet.exists>> |Caps facet counts by one. Available only for `facet.method=enum` as performance optimization.
-|<<Faceting-Thefacet.excludeTermsParameter,facet.excludeTerms>> |Removes specific terms from facet counts. This allows you to exclude certain terms from faceting, while maintaining the terms in the index for general queries.
-|<<Faceting-Thefacet.enum.cache.minDfParameter,facet.enum.cache.minDf>> |(Advanced) Specifies the minimum document frequency (the number of documents matching a term) for which the `filterCache` should be used when determining the constraint count for that term.
-|<<Faceting-Over-RequestParameters,facet.overrequest.count>> |(Advanced) A number of documents, beyond the effective `facet.limit` to request from each shard in a distributed search
-|<<Faceting-Over-RequestParameters,facet.overrequest.ratio>> |(Advanced) A multiplier of the effective `facet.limit` to request from each shard in a distributed search
-|<<Faceting-Thefacet.threadsParameter,facet.threads>> |(Advanced) Controls parallel execution of field faceting
-|===
-
-These parameters are described in the sections below.
-
-[[Faceting-Thefacet.fieldParameter]]
-=== The facet.field Parameter
+Unless otherwise specified, all of the parameters below can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.<parameter>`
+`facet.field`::
The `facet.field` parameter identifies a field that should be treated as a facet. It iterates over each Term in the field and generate a facet count using that Term as the constraint. This parameter can be specified multiple times in a query to select multiple facet fields.
++
+IMPORTANT: If you do not set this parameter to at least one field in the schema, none of the other parameters described in this section will have any effect.
-[IMPORTANT]
-====
-If you do not set this parameter to at least one field in the schema, none of the other parameters described in this section will have any effect.
-====
-
-[[Faceting-Thefacet.prefixParameter]]
-=== The facet.prefix Parameter
-
+`facet.prefix`::
The `facet.prefix` parameter limits the terms on which to facet to those starting with the given string prefix. This does not limit the query in any way, only the facets that would be returned in response to the query.
++
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.prefix`.
-
-[[Faceting-Thefacet.containsParameter]]
-=== The facet.contains Parameter
-
+`facet.contains`::
The `facet.contains` parameter limits the terms on which to facet to those containing the given substring. This does not limit the query in any way, only the facets that would be returned in response to the query.
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.contains`.
-
-[[Faceting-Thefacet.contains.ignoreCaseParameter]]
-=== The facet.contains.ignoreCase Parameter
+`facet.contains.ignoreCase`::
If `facet.contains` is used, the `facet.contains.ignoreCase` parameter causes case to be ignored when matching the given substring against candidate facet terms.
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.contains.ignoreCase`.
-
-[[Faceting-Thefacet.sortParameter]]
-=== The facet.sort Parameter
-
+`facet.sort`::
This parameter determines the ordering of the facet field constraints.
-
++
There are two options for this parameter.
-
-count:: Sort the constraints by count (highest count first).
-index:: Return the constraints sorted in their index order (lexicographic by indexed term). For terms in the ASCII range, this will be alphabetically sorted.
-
++
+--
+`count`::: Sort the constraints by count (highest count first).
+`index`::: Return the constraints sorted in their index order (lexicographic by indexed term). For terms in the ASCII range, this will be alphabetically sorted.
+--
++
The default is `count` if `facet.limit` is greater than 0, otherwise, the default is `index`.
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.sort`.
-
-[[Faceting-Thefacet.limitParameter]]
-=== The facet.limit Parameter
-
+`facet.limit`::
This parameter specifies the maximum number of constraint counts (essentially, the number of facets for a field that are returned) that should be returned for the facet fields. A negative value means that Solr will return unlimited number of constraint counts.
++
+The default value is `100`.
-The default value is 100.
-
-This parameter can be specified on a per-field basis to apply a distinct limit to each field with the syntax of `f.<fieldname>.facet.limit`.
-
-[[Faceting-Thefacet.offsetParameter]]
-=== The facet.offset Parameter
+`facet.offset`::
The `facet.offset` parameter indicates an offset into the list of constraints to allow paging.
++
+The default value is `0`.
-The default value is 0.
-
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.offset`.
-
-[[Faceting-Thefacet.mincountParameter]]
-=== The facet.mincount Parameter
+`facet.mincount`::
The `facet.mincount` parameter specifies the minimum counts required for a facet field to be included in the response. If a field's counts are below the minimum, the field's facet is not returned.
++
+The default value is `0`.
-The default value is 0.
-
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.mincount`.
-
-[[Faceting-Thefacet.missingParameter]]
-=== The facet.missing Parameter
-
-If set to true, this parameter indicates that, in addition to the Term-based constraints of a facet field, a count of all results that match the query but which have no facet value for the field should be computed and returned in the response.
-
-The default value is false.
-
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.missing`.
-
-[[Faceting-Thefacet.methodParameter]]
-=== The facet.method Parameter
-
-The facet.method parameter selects the type of algorithm or method Solr should use when faceting a field.
+`facet.missing`::
+If set to `true`, this parameter indicates that, in addition to the Term-based constraints of a facet field, a count of all results that match the query but which have no facet value for the field should be computed and returned in the response.
++
+The default value is `false`.
+`facet.method`::
+The `facet.method` parameter selects the type of algorithm or method Solr should use when faceting a field.
++
The following methods are available.
-
-enum:: Enumerates all terms in a field, calculating the set intersection of documents that match the term with documents that match the query.
++
+--
+`enum`::: Enumerates all terms in a field, calculating the set intersection of documents that match the term with documents that match the query.
+
This method is recommended for faceting multi-valued fields that have only a few distinct values. The average number of values per document does not matter.
+
For example, faceting on a field with U.S. States such as `Alabama, Alaska, ... Wyoming` would lead to fifty cached filters which would be used over and over again. The `filterCache` should be large enough to hold all the cached filters.
-fc:: Calculates facet counts by iterating over documents that match the query and summing the terms that appear in each document.
+`fc`::: Calculates facet counts by iterating over documents that match the query and summing the terms that appear in each document.
+
This is currently implemented using an `UnInvertedField` cache if the field either is multi-valued or is tokenized (according to `FieldType.isTokened()`). Each document is looked up in the cache to see what terms/values it contains, and a tally is incremented for each value.
+
This method is excellent for situations where the number of indexed values for the field is high, but the number of values per document is low. For multi-valued fields, a hybrid approach is used that uses term filters from the `filterCache` for terms that match many documents. The letters `fc` stand for field cache.
-fcs:: Per-segment field faceting for single-valued string fields. Enable with `facet.method=fcs` and control the number of threads used with the `threads` local parameter. This parameter allows faceting to be faster in the presence of rapid index changes.
-
+`fcs`::: Per-segment field faceting for single-valued string fields. Enable with `facet.method=fcs` and control the number of threads used with the `threads` local parameter. This parameter allows faceting to be faster in the presence of rapid index changes.
+--
++
The default value is `fc` (except for fields using the `BoolField` field type and when `facet.exists=true` is requested) since it tends to use less memory and is faster when a field has many unique terms in the index.
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.method`.
-
-[[Faceting-Thefacet.enum.cache.minDfParameter]]
-=== The facet.enum.cache.minDf Parameter
-
+`facet.enum.cache.minDf`::
This parameter indicates the minimum document frequency (the number of documents matching a term) for which the filterCache should be used when determining the constraint count for that term. This is only used with the `facet.method=enum` method of faceting.
++
+A value greater than zero decreases the filterCache's memory usage, but increases the time required for the query to be processed. If you are faceting on a field with a very large number of terms, and you wish to decrease memory usage, try setting this parameter to a value between `25` and `50`, and run a few tests. Then, optimize the parameter setting as necessary.
++
+The default value is `0`, causing the filterCache to be used for all terms in the field.
-A value greater than zero decreases the filterCache's memory usage, but increases the time required for the query to be processed. If you are faceting on a field with a very large number of terms, and you wish to decrease memory usage, try setting this parameter to a value between 25 and 50, and run a few tests. Then, optimize the parameter setting as necessary.
-
-The default value is 0, causing the filterCache to be used for all terms in the field.
-
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.enum.cache.minDf`.
-
-[[Faceting-Thefacet.existsParameter]]
-=== The facet.exists Parameter
-
-To cap facet counts by 1, specify `facet.exists=true`. It can be used with `facet.method=enum` or when it's omitted. It can be used only on non-trie fields (such as strings). It may speed up facet counting on large indices and/or high-cardinality facet values..
-
-This parameter can be specified on a per-field basis with the syntax of `f.<fieldname>.facet.exists` or via local parameter` facet.field={!facet.method=enum facet.exists=true}size`.
+`facet.exists`::
+To cap facet counts by 1, specify `facet.exists=true`. This parameter can be used with `facet.method=enum` or when it's omitted. It can be used only on non-trie fields (such as strings). It may speed up facet counting on large indices and/or high-cardinality facet values.
-[[Faceting-Thefacet.excludeTermsParameter]]
-=== The facet.excludeTerms Parameter
+`facet.excludeTerms`::
If you want to remove terms from facet counts but keep them in the index, the `facet.excludeTerms` parameter allows you to do that.
-[[Faceting-Over-RequestParameters]]
-=== Over-Request Parameters
-
-In some situations, the accuracy in selecting the "top" constraints returned for a facet in a distributed Solr query can be improved by "Over Requesting" the number of desired constraints (ie: `facet.limit`) from each of the individual Shards. In these situations, each shard is by default asked for the top "`10 + (1.5 * facet.limit)`" constraints.
-
-In some situations, depending on how your docs are partitioned across your shards, and what `facet.limit` value you used, you may find it advantageous to increase or decrease the amount of over-requesting Solr does. This can be achieved by setting the `facet.overrequest.count` (defaults to 10) and `facet.overrequest.ratio` (defaults to 1.5) parameters.
-
-[[Faceting-Thefacet.threadsParameter]]
-=== The facet.threads Parameter
+`facet.overrequest.count` and `facet.overrequest.ratio`::
+In some situations, the accuracy in selecting the "top" constraints returned for a facet in a distributed Solr query can be improved by "over requesting" the number of desired constraints (i.e., `facet.limit`) from each of the individual shards. In these situations, each shard is by default asked for the top `10 + (1.5 * facet.limit)` constraints.
++
+In some situations, depending on how your docs are partitioned across your shards and what `facet.limit` value you used, you may find it advantageous to increase or decrease the amount of over-requesting Solr does. This can be achieved by setting the `facet.overrequest.count` (defaults to `10`) and `facet.overrequest.ratio` (defaults to `1.5`) parameters.
-This param will cause loading the underlying fields used in faceting to be executed in parallel with the number of threads specified. Specify as `facet.threads=N` where `N` is the maximum number of threads used. Omitting this parameter or specifying the thread count as 0 will not spawn any threads, and only the main request thread will be used. Specifying a negative number of threads will create up to Integer.MAX_VALUE threads.
+`facet.threads`::
+This parameter will cause loading the underlying fields used in faceting to be executed in parallel with the number of threads specified. Specify as `facet.threads=N` where `N` is the maximum number of threads used.
++
+Omitting this parameter or specifying the thread count as `0` will not spawn any threads, and only the main request thread will be used. Specifying a negative number of threads will create up to `Integer.MAX_VALUE` threads.
-[[Faceting-RangeFaceting]]
== Range Faceting
You can use Range Faceting on any date field or any numeric field that supports range queries. This is particularly useful for stitching together a series of range queries (as facet by query) for things like prices.
-// 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
-|<<Faceting-Thefacet.rangeParameter,facet.range>> |Specifies the field to facet by range.
-|<<Faceting-Thefacet.range.startParameter,facet.range.start>> |Specifies the start of the facet range.
-|<<Faceting-Thefacet.range.endParameter,facet.range.end>> |Specifies the end of the facet range.
-|<<Faceting-Thefacet.range.gapParameter,facet.range.gap>> |Specifies the span of the range as a value to be added to the lower bound.
-|<<Faceting-Thefacet.range.hardendParameter,facet.range.hardend>> |A boolean parameter that specifies how Solr handles a range gap that cannot be evenly divided between the range start and end values. If true, the last range constraint will have the `facet.range.end` value an upper bound. If false, the last range will have the smallest possible upper bound greater then `facet.range.end` such that the range is the exact width of the specified range gap. The default value for this parameter is false.
-|<<Faceting-Thefacet.range.includeParameter,facet.range.include>> |Specifies inclusion and exclusion preferences for the upper and lower bounds of the range. See the `facet.range.include` topic for more detailed information.
-|<<Faceting-Thefacet.range.otherParameter,facet.range.other>> |Specifies counts for Solr to compute in addition to the counts for each facet range constraint.
-|<<Faceting-Thefacet.range.methodParameter,facet.range.method>> |Specifies the algorithm or method to use for calculating facets.
-|===
-
-[[Faceting-Thefacet.rangeParameter]]
-=== The facet.range Parameter
-
+`facet.range`::
The `facet.range` parameter defines the field for which Solr should create range facets. For example:
-
++
`facet.range=price&facet.range=age`
-
++
`facet.range=lastModified_dt`
-[[Faceting-Thefacet.range.startParameter]]
-=== The facet.range.start Parameter
-
+`facet.range.start`::
The `facet.range.start` parameter specifies the lower bound of the ranges. You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.start`. For example:
-
++
`f.price.facet.range.start=0.0&f.age.facet.range.start=10`
-
++
`f.lastModified_dt.facet.range.start=NOW/DAY-30DAYS`
-[[Faceting-Thefacet.range.endParameter]]
-=== The facet.range.end Parameter
-
-The facet.range.end specifies the upper bound of the ranges. You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.end`. For example:
-
+`facet.range.end`::
+The `facet.range.end` specifies the upper bound of the ranges. You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.end`. For example:
++
`f.price.facet.range.end=1000.0&f.age.facet.range.start=99`
-
++
`f.lastModified_dt.facet.range.end=NOW/DAY+30DAYS`
-[[Faceting-Thefacet.range.gapParameter]]
-=== The facet.range.gap Parameter
-
+`facet.range.gap`::
The span of each range expressed as a value to be added to the lower bound. For date fields, this should be expressed using the {solr-javadocs}/solr-core/org/apache/solr/util/DateMathParser.html[`DateMathParser` syntax] (such as, `facet.range.gap=%2B1DAY ... '+1DAY'`). You can specify this parameter on a per-field basis with the syntax of `f.<fieldname>.facet.range.gap`. For example:
-
++
`f.price.facet.range.gap=100&f.age.facet.range.gap=10`
-
++
`f.lastModified_dt.facet.range.gap=+1DAY`
-[[Faceting-Thefacet.range.hardendParameter]]
-=== The facet.range.hardend Parameter
-
+`facet.range.hardend`::
The `facet.range.hardend` parameter is a Boolean parameter that specifies how Solr should handle cases where the `facet.range.gap` does not divide evenly between `facet.range.start` and `facet.range.end`.
-
-If *true*, the last range constraint will have the `facet.range.end` value as an upper bound. If *false*, the last range will have the smallest possible upper bound greater then `facet.range.end` such that the range is the exact width of the specified range gap. The default value for this parameter is false.
-
++
+If `true`, the last range constraint will have the `facet.range.end` value as an upper bound. If `false`, the last range will have the smallest possible upper bound greater then `facet.range.end` such that the range is the exact width of the specified range gap. The default value for this parameter is false.
++
This parameter can be specified on a per field basis with the syntax `f.<fieldname>.facet.range.hardend`.
-[[Faceting-Thefacet.range.includeParameter]]
-=== The facet.range.include Parameter
-
+`facet.range.include`::
By default, the ranges used to compute range faceting between `facet.range.start` and `facet.range.end` are inclusive of their lower bounds and exclusive of the upper bounds. The "before" range defined with the `facet.range.other` parameter is exclusive and the "after" range is inclusive. This default, equivalent to "lower" below, will not result in double counting at the boundaries. You can use the `facet.range.include` parameter to modify this behavior using the following options:
-
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
-
-[cols="30,70",options="header"]
-|===
-|Option |Description
-|lower |All gap-based ranges include their lower bound.
-|upper |All gap-based ranges include their upper bound.
-|edge |The first and last gap ranges include their edge bounds (lower for the first one, upper for the last one) even if the corresponding upper/lower option is not specified.
-|outer |The "before" and "after" ranges will be inclusive of their bounds, even if the first or last ranges already include those boundaries.
-|all |Includes all options: lower, upper, edge, outer.
-|===
-
++
+--
+* `lower`: All gap-based ranges include their lower bound.
+* `upper`: All gap-based ranges include their upper bound.
+* `edge`: The first and last gap ranges include their edge bounds (lower for the first one, upper for the last one) even if the corresponding upper/lower option is not specified.
+* `outer`: The "before" and "after" ranges will be inclusive of their bounds, even if the first or last ranges already include those boundaries.
+* `all`: Includes all options: `lower`, `upper`, `edge`, and `outer`.
+--
++
You can specify this parameter on a per field basis with the syntax of `f.<fieldname>.facet.range.include`, and you can specify it multiple times to indicate multiple choices.
++
+NOTE: To ensure you avoid double-counting, do not choose both `lower` and `upper`, do not choose `outer`, and do not choose `all`.
-[NOTE]
-====
-To ensure you avoid double-counting, do not choose both `lower` and `upper`, do not choose `outer`, and do not choose `all`.
-====
-
-[[Faceting-Thefacet.range.otherParameter]]
-=== The facet.range.other Parameter
-
+`facet.range.other`::
The `facet.range.other` parameter specifies that in addition to the counts for each range constraint between `facet.range.start` and `facet.range.end`, counts should also be computed for these options:
-
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
-
-[cols="30,70",options="header"]
-|===
-|Option |Description
-|before |All records with field values lower then lower bound of the first range.
-|after |All records with field values greater then the upper bound of the last range.
-|between |All records with field values between the start and end bounds of all ranges.
-|none |Do not compute any counts.
-|all |Compute counts for before, between, and after.
-|===
-
++
+--
+* `before`: All records with field values lower then lower bound of the first range.
+* `after`: All records with field values greater then the upper bound of the last range.
+* `between`: All records with field values between the start and end bounds of all ranges.
+* `none`: Do not compute any counts.
+* `all`: Compute counts for before, between, and after.
+--
++
This parameter can be specified on a per field basis with the syntax of `f.<fieldname>.facet.range.other`. In addition to the `all` option, this parameter can be specified multiple times to indicate multiple choices, but `none` will override all other options.
-[[Faceting-Thefacet.range.methodParameter]]
-=== The facet.range.method Parameter
-
+`facet.range.method`::
The `facet.range.method` parameter selects the type of algorithm or method Solr should use for range faceting. Both methods produce the same results, but performance may vary.
++
+--
+filter::: This method generates the ranges based on other facet.range parameters, and for each of them executes a filter that later intersects with the main query resultset to get the count. It will make use of the filterCache, so it will benefit of a cache large enough to contain all ranges.
++
+dv::: This method iterates the documents that match the main query, and for each of them finds the correct range for the value. This method will make use of <<docvalues.adoc#docvalues,docValues>> (if enabled for the field) or fieldCache. The `dv` method is not supported for field type DateRangeField or when using <<result-grouping.adoc#result-grouping,group.facets>>.
+--
++
+The default value for this parameter is `filter`.
-filter:: This method generates the ranges based on other facet.range parameters, and for each of them executes a filter that later intersects with the main query resultset to get the count. It will make use of the filterCache, so it will benefit of a cache large enough to contain all ranges.
-
-dv:: This method iterates the documents that match the main query, and for each of them finds the correct range for the value. This method will make use of <<docvalues.adoc#docvalues,docValues>> (if enabled for the field) or fieldCache. The `dv` method is not supported for field type DateRangeField or when using <<result-grouping.adoc#result-grouping,group.facets>>.
-
-Default value for this parameter is "filter".
-
-[[Faceting-Thefacet.mincountParameterinRangeFaceting]]
-=== The facet.mincount Parameter in Range Faceting
-The `facet.mincount` parameter, the same one as used in field faceting is also applied to range faceting. When used, no ranges with a count below the minimum will be included in the response.
.Date Ranges & Time Zones
[NOTE]
====
-
Range faceting on date fields is a common situation where the <<working-with-dates.adoc#tz,`TZ`>> parameter can be useful to ensure that the "facet counts per day" or "facet counts per month" are based on a meaningful definition of when a given day/month "starts" relative to a particular TimeZone.
For more information, see the examples in the <<working-with-dates.adoc#working-with-dates,Working with Dates>> section.
-
====
+=== facet.mincount in Range Faceting
+
+The `facet.mincount` parameter, the same one as used in field faceting is also applied to range faceting. When used, no ranges with a count below the minimum will be included in the response.
-[[Faceting-Pivot_DecisionTree_Faceting]]
== Pivot (Decision Tree) Faceting
Pivoting is a summarization tool that lets you automatically sort, count, total or average data stored in a table. The results are typically displayed in a second table showing the summarized data. Pivot faceting lets you create a summary table of the results from a faceting documents by multiple fields.
Another way to look at it is that the query produces a Decision Tree, in that Solr tells you "for facet A, the constraints/counts are X/N, Y/M, etc. If you were to constrain A by X, then the constraint counts for B would be S/P, T/Q, etc.". In other words, it tells you in advance what the "next" set of facet results would be for a field if you apply a constraint from the current facet results.
-[[Faceting-facet.pivot]]
-=== facet.pivot
-
+`facet.pivot`::
The `facet.pivot` parameter defines the fields to use for the pivot. Multiple `facet.pivot` values will create multiple "facet_pivot" sections in the response. Separate each list of fields with a comma.
-[[Faceting-facet.pivot.mincount]]
-=== facet.pivot.mincount
-
+`facet.pivot.mincount`::
The `facet.pivot.mincount` parameter defines the minimum number of documents that need to match in order for the facet to be included in results. The default is 1.
-
++
Using the "`bin/solr -e techproducts`" example, A query URL like this one will return the data below, with the pivot faceting results found in the section "facet_pivot":
-
++
[source,text]
----
http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity,inStock
&facet.pivot=popularity,cat&facet=true&facet.field=cat&facet.limit=5
&rows=0&wt=json&indent=true&facet.pivot.mincount=2
----
-
++
[source,json]
----
{ "facet_counts":{
@@ -413,10 +290,9 @@ http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity,
}]}}}
----
-[[Faceting-CombiningStatsComponentWithPivots]]
=== Combining Stats Component With Pivots
-In addition to some of the <<Faceting-LocalParametersforFaceting,general local parameters>> supported by other types of faceting, a `stats` local parameters can be used with `facet.pivot` to refer to <<the-stats-component.adoc#the-stats-component,`stats.field`>> instances (by tag) that you would like to have computed for each Pivot Constraint.
+In addition to some of the <<Local Parameters for Faceting,general local parameters>> supported by other types of faceting, a `stats` local parameters can be used with `facet.pivot` to refer to <<the-stats-component.adoc#the-stats-component,`stats.field`>> instances (by tag) that you would like to have computed for each Pivot Constraint.
In the example below, two different (overlapping) sets of statistics are computed for each of the facet.pivot result hierarchies:
@@ -503,7 +379,6 @@ Results:
"..."}]}}}}]}]}}
----
-[[Faceting-CombiningFacetQueriesAndFacetRangesWithPivotFacets]]
=== Combining Facet Queries And Facet Ranges With Pivot Facets
A `query` local parameter can be used with `facet.pivot` to refer to `facet.query` instances (by tag) that should be computed for each pivot constraint. Similarly, a `range` local parameter can be used with `facet.pivot` to refer to `facet.range` instances.
@@ -630,10 +505,9 @@ facet.pivot={!range=r1}cat,inStock
"..."]}]}}}
----
-[[Faceting-AdditionalPivotParameters]]
=== Additional Pivot Parameters
-Although `facet.pivot.mincount` deviates in name from the `facet.mincount` parameter used by field faceting, many other Field faceting parameters described above can also be used with pivot faceting:
+Although `facet.pivot.mincount` deviates in name from the `facet.mincount` parameter used by field faceting, many of the faceting parameters described above can also be used with pivot faceting:
* `facet.limit`
* `facet.offset`
@@ -641,7 +515,6 @@ Although `facet.pivot.mincount` deviates in name from the `facet.mincount` param
* `facet.overrequest.count`
* `facet.overrequest.ratio`
-[[Faceting-IntervalFaceting]]
== Interval Faceting
Another supported form of faceting is interval faceting. This sounds similar to range faceting, but the functionality is really closer to doing facet queries with range queries. Interval faceting allows you to set variable intervals and count the number of documents that have values within those intervals in the specified field.
@@ -652,23 +525,21 @@ If you are concerned about the performance of your searches you should test with
This method will use <<docvalues.adoc#docvalues,docValues>> if they are enabled for the field, will use fieldCache otherwise.
-[[Faceting-Thefacet.intervalparameter]]
-=== The facet.interval parameter
+Use these parameters for interval faceting:
-This parameter Indicates the field where interval faceting must be applied. It can be used multiple times in the same request to indicate multiple fields.
+`facet.interval`::
+This parameter Indicates the field where interval faceting must be applied. It can be used multiple times in the same request to indicate multiple fields.
++
`facet.interval=price&facet.interval=size`
-[[Faceting-Thefacet.interval.setparameter]]
-=== The facet.interval.set parameter
-
+`facet.interval.set`::
This parameter is used to set the intervals for the field, it can be specified multiple times to indicate multiple intervals. This parameter is global, which means that it will be used for all fields indicated with `facet.interval` unless there is an override for a specific field. To override this parameter on a specific field you can use: `f.<fieldname>.facet.interval.set`, for example:
-
++
[source,text]
f.price.facet.interval.set=[0,10]&f.price.facet.interval.set=(10,100]
-[[Faceting-IntervalSyntax]]
=== Interval Syntax
Intervals must begin with either '(' or '[', be followed by the start value, then a comma (','), the end value, and finally a closing ')' or ']’.
@@ -699,12 +570,10 @@ Interval faceting supports output key replacement described below. Output keys c
&facet=true
----
-[[Faceting-LocalParametersforFaceting]]
== Local Parameters for Faceting
The <<local-parameters-in-queries.adoc#local-parameters-in-queries,LocalParams syntax>> allows overriding global settings. It can also provide a method of adding metadata to other parameter values, much like XML attributes.
-[[Faceting-TaggingandExcludingFilters]]
=== Tagging and Excluding Filters
You can tag specific filters and exclude those filters when faceting. This is useful when doing multi-select faceting.
@@ -732,7 +601,6 @@ To return counts for doctype values that are currently not selected, tag filters
Filter exclusion is supported for all types of facets. Both the `tag` and `ex` local parameters may specify multiple values by separating them with commas.
-[[Faceting-ChangingtheOutputKey]]
=== Changing the Output Key
To change the output key for a faceting command, specify a new name with the `key` local parameter. For example:
@@ -741,14 +609,12 @@ To change the output key for a faceting command, specify a new name with the `ke
The parameter setting above causes the field facet results for the "doctype" field to be returned using the key "mylabel" rather than "doctype" in the response. This can be helpful when faceting on the same field multiple times with different exclusions.
-[[Faceting-Limitingfacetwithcertainterms]]
=== Limiting Facet with Certain Terms
To limit field facet with certain terms specify them comma separated with `terms` local parameter. Commas and quotes in terms can be escaped with backslash, as in `\,`. In this case facet is calculated on a way similar to `facet.method=enum` , but ignores `facet.enum.cache.minDf`. For example:
`facet.field={!terms='alfa,betta,with\,with\',with space'}symbol`
-[[Faceting-RelatedTopics]]
== Related Topics
-* <<spatial-search.adoc#spatial-search,Heatmap Faceting (Spatial)>>
+See also <<spatial-search.adoc#spatial-search,Heatmap Faceting (Spatial)>>.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
index 695146b..c3c1b5d 100644
--- a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
+++ b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
@@ -90,11 +90,11 @@ For multivalued fields, specifies a distance between multiple values, which prev
`autoGeneratePhraseQueries`:: For text fields. If `true`, Solr automatically generates phrase queries for adjacent terms. If `false`, terms must be enclosed in double-quotes to be treated as phrases.
`enableGraphQueries`::
-For text fields, applicable when querying with <<the-standard-query-parser.adoc#TheStandardQueryParser-StandardQueryParserParameters,`sow=false`>>. Use `true` (the default) for field types with query analyzers including graph-aware filters, e.g., <<filter-descriptions.adoc#synonym-graph-filter,Synonym Graph Filter>> and <<filter-descriptions.adoc#word-delimiter-graph-filter,Word Delimiter Graph Filter>>.
+For text fields, applicable when querying with <<the-standard-query-parser.adoc#standard-query-parser-parameters,`sow=false`>>. Use `true` (the default) for field types with query analyzers including graph-aware filters, e.g., <<filter-descriptions.adoc#synonym-graph-filter,Synonym Graph Filter>> and <<filter-descriptions.adoc#word-delimiter-graph-filter,Word Delimiter Graph Filter>>.
+
Use `false` for field types with query analyzers including filters that can match docs when some tokens are missing, e.g., <<filter-descriptions.adoc#shingle-filter,Shingle Filter>>.
-[[FieldTypeDefinitionsandProperties-docValuesFormat]]
+[[docvaluesformat]]
`docValuesFormat`::
Defines a custom `DocValuesFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory` has been configured in solrconfig.xml.
@@ -130,7 +130,7 @@ The default values for each property depend on the underlying `FieldType` class,
|omitPositions |Similar to `omitTermFreqAndPositions` but preserves term frequency information. |true or false |*
|termVectors termPositions termOffsets termPayloads |These options instruct Solr to maintain full term vectors for each document, optionally including position, offset and payload information for each term occurrence in those vectors. These can be used to accelerate highlighting and other ancillary functionality, but impose a substantial cost in terms of index size. They are not necessary for typical uses of Solr. |true or false |false
|required |Instructs Solr to reject any attempts to add a document which does not have a value for this field. This property defaults to false. |true or false |false
-|useDocValuesAsStored |If the field has <<docvalues.adoc#docvalues,docValues>> enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <<common-query-parameters.adoc#CommonQueryParameters-Thefl_FieldList_Parameter,fl parameter>>. |true or false |true
+|useDocValuesAsStored |If the field has <<docvalues.adoc#docvalues,docValues>> enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <<common-query-parameters.adoc#fl-field-list-parameter,fl parameter>>. |true or false |true
|large |Large fields are always lazy loaded and will only take up space in the document cache if the actual value is < 512KB. This option requires `stored="true"` and `multiValued="false"`. It's intended for fields that might have very large values so that they don't get cached in memory. |true or false |false
|===
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/function-queries.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/function-queries.adoc b/solr/solr-ref-guide/src/function-queries.adoc
index 5a9f6df..11dfb08 100644
--- a/solr/solr-ref-guide/src/function-queries.adoc
+++ b/solr/solr-ref-guide/src/function-queries.adoc
@@ -60,7 +60,7 @@ the output would be:
<float name="score">0.343</float>
...
----
-* Use in a parameter that is explicitly for specifying functions, such as the EDisMax query parser's <<the-extended-dismax-query-parser.adoc#the-extended-dismax-query-parser,`boost`>> param, or DisMax query parser's <<the-dismax-query-parser.adoc#TheDisMaxQueryParser-Thebf_BoostFunctions_Parameter,`bf` (boost function) parameter>>. (Note that the `bf` parameter actually takes a list of function queries separated by white space and each with an optional boost. Make sure you eliminate any internal white space in single function queries when using `bf`). For example:
+* Use in a parameter that is explicitly for specifying functions, such as the EDisMax query parser's <<the-extended-dismax-query-parser.adoc#the-extended-dismax-query-parser,`boost`>> param, or DisMax query parser's <<the-dismax-query-parser.adoc#bf-boost-functions-parameter,`bf` (boost function) parameter>>. (Note that the `bf` parameter actually takes a list of function queries separated by white space and each with an optional boost. Make sure you eliminate any internal white space in single function queries when using `bf`). For example:
+
[source,text]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc b/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc
index a592a2d..d81936f 100644
--- a/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc
@@ -108,7 +108,7 @@ If the configuration options for the built-in merge policies do not fully suit y
</mergePolicyFactory>
----
-The example above shows Solr's {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] being configured to sort documents in merged segments by `"timestamp desc"`, and wrapped around a `TieredMergePolicyFactory` configured to use the values `maxMergeAtOnce=10` and `segmentsPerTier=10` via the `inner` prefix defined by `SortingMergePolicyFactory` 's `wrapped.prefix` option. For more information on using `SortingMergePolicyFactory`, see <<common-query-parameters.adoc#CommonQueryParameters-ThesegmentTerminateEarlyParameter,the segmentTerminateEarly parameter>>.
+The example above shows Solr's {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] being configured to sort documents in merged segments by `"timestamp desc"`, and wrapped around a `TieredMergePolicyFactory` configured to use the values `maxMergeAtOnce=10` and `segmentsPerTier=10` via the `inner` prefix defined by `SortingMergePolicyFactory` 's `wrapped.prefix` option. For more information on using `SortingMergePolicyFactory`, see <<common-query-parameters.adoc#segmentterminateearly-parameter,the segmentTerminateEarly parameter>>.
=== mergeScheduler
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/query-re-ranking.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/query-re-ranking.adoc b/solr/solr-ref-guide/src/query-re-ranking.adoc
index f05af72..b633064 100644
--- a/solr/solr-ref-guide/src/query-re-ranking.adoc
+++ b/solr/solr-ref-guide/src/query-re-ranking.adoc
@@ -67,4 +67,4 @@ The `ltr` stands for Learning To Rank, please see <<learning-to-rank.adoc#learni
== Combining Ranking Queries with Other Solr Features
-The `rq` parameter and the re-ranking feature in general works well with other Solr features. For example, it can be used in conjunction with the <<collapse-and-expand-results.adoc#collapse-and-expand-results,collapse parser>> to re-rank the group heads after they've been collapsed. It also preserves the order of documents elevated by the <<the-query-elevation-component.adoc#the-query-elevation-component,elevation component>>. And it even has its own custom explain so you can see how the re-ranking scores were derived when looking at <<common-query-parameters.adoc#CommonQueryParameters-ThedebugParameter,debug information>>.
+The `rq` parameter and the re-ranking feature in general works well with other Solr features. For example, it can be used in conjunction with the <<collapse-and-expand-results.adoc#collapse-and-expand-results,collapse parser>> to re-rank the group heads after they've been collapsed. It also preserves the order of documents elevated by the <<the-query-elevation-component.adoc#the-query-elevation-component,elevation component>>. And it even has its own custom explain so you can see how the re-ranking scores were derived when looking at <<common-query-parameters.adoc#debug-parameter,debug information>>.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/realtime-get.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/realtime-get.adoc b/solr/solr-ref-guide/src/realtime-get.adoc
index 0573e05..f7d1036 100644
--- a/solr/solr-ref-guide/src/realtime-get.adoc
+++ b/solr/solr-ref-guide/src/realtime-get.adoc
@@ -94,7 +94,7 @@ http://localhost:8983/solr/techproducts/get?id=mydoc&id=IW-02
}
----
-Real Time Get requests can also be combined with filter queries, specified with an <<common-query-parameters.adoc#CommonQueryParameters-Thefq_FilterQuery_Parameter,`fq` parameter>>, just like search requests:
+Real Time Get requests can also be combined with filter queries, specified with an <<common-query-parameters.adoc#fq-filter-query-parameter,`fq` parameter>>, just like search requests:
[source,text]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bbae31b9/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc b/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc
index 10fabab..f043e84 100644
--- a/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc
@@ -65,7 +65,7 @@ All of the parameters described in the section <<searching.adoc#searching,Searc
Besides `defaults`, there are other options for the SearchHandler, which are:
-* `appends`: This allows definition of parameters that are added to the user query. These might be <<common-query-parameters.adoc#CommonQueryParameters-Thefq_FilterQuery_Parameter,filter queries>>, or other query rules that should be added to each query. There is no mechanism in Solr to allow a client to override these additions, so you should be absolutely sure you always want these parameters applied to queries.
+* `appends`: This allows definition of parameters that are added to the user query. These might be <<common-query-parameters.adoc#fq-filter-query-parameter,filter queries>>, or other query rules that should be added to each query. There is no mechanism in Solr to allow a client to override these additions, so you should be absolutely sure you always want these parameters applied to queries.
+
[source,xml]
----
@@ -125,7 +125,7 @@ There are several default search components that work with all SearchHandlers wi
|mlt |`solr.MoreLikeThisComponent` |Described in the section <<morelikethis.adoc#morelikethis,MoreLikeThis>>.
|highlight |`solr.HighlightComponent` |Described in the section <<highlighting.adoc#highlighting,Highlighting>>.
|stats |`solr.StatsComponent` |Described in the section <<the-stats-component.adoc#the-stats-component,The Stats Component>>.
-|debug |`solr.DebugComponent` |Described in the section on <<common-query-parameters.adoc#CommonQueryParameters-ThedebugParameter,Common Query Parameters>>.
+|debug |`solr.DebugComponent` |Described in the section on <<common-query-parameters.adoc#debug-parameter,Common Query Parameters>>.
|expand |`solr.ExpandComponent` |Described in the section <<collapse-and-expand-results.adoc#collapse-and-expand-results,Collapse and Expand Results>>.
|===