From b32dcbbe42bd3360f6d1cfa65495f7007034d0a9 Mon Sep 17 00:00:00 2001 From: Cassandra Targett Date: Wed, 12 Sep 2018 15:04:28 -0500 Subject: [PATCH] Ref Guide: fix typos; params -> parameters --- .../src/common-query-parameters.adoc | 4 ++-- .../src/initparams-in-solrconfig.adoc | 2 +- solr/solr-ref-guide/src/other-parsers.adoc | 6 ++--- .../src/pagination-of-results.adoc | 2 +- .../src/resource-and-plugin-loading.adoc | 24 +++++++++---------- .../src/rule-based-replica-placement.adoc | 2 +- solr/solr-ref-guide/src/spell-checking.adoc | 2 +- ...transforming-and-indexing-custom-json.adoc | 2 +- 8 files changed, 22 insertions(+), 22 deletions(-) diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc index 3f3564f44ab..fe2956e5463 100644 --- a/solr/solr-ref-guide/src/common-query-parameters.adoc +++ b/solr/solr-ref-guide/src/common-query-parameters.adoc @@ -284,9 +284,9 @@ The `echoParams` parameter controls what information about request parameters is The `echoParams` parameter accepts the following values: -* `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. +* `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. +* `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`: diff --git a/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc b/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc index 733402199a9..c0b7fb32a50 100644 --- a/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc @@ -46,7 +46,7 @@ The syntax and semantics are similar to that of a ``. The follow A comma-separated list of paths which will use the parameters. Wildcards can be used in paths to define nested paths, as described below. `name`:: -The name of this set of parameters. The name can be used directly in a requestHandler definition if a path is not explicitly named. If you give your `` a name, you can refer to the params in a `` that is not defined as a path. +The name of this set of parameters. The name can be used directly in a requestHandler definition if a path is not explicitly named. If you give your `` a name, you can refer to the parameters in a `` that is not defined as a path. + For example, if an `` section has the name "myParams", you can call the name when defining your request handler: + diff --git a/solr/solr-ref-guide/src/other-parsers.adoc b/solr/solr-ref-guide/src/other-parsers.adoc index bcd28eba24d..f22dcdc0599 100644 --- a/solr/solr-ref-guide/src/other-parsers.adoc +++ b/solr/solr-ref-guide/src/other-parsers.adoc @@ -498,11 +498,11 @@ http://localhost:8983/solr/my_graph/query?fl=id&q={!graph+from=in_edge+to=out_ed === Simplified Models -The Document & Field modeling used in the above examples enumerated all of the outgoing and income edges for each node explicitly, to help demonstrate exactly how the "from" and "to" params work, and to give you an idea of what is possible. With multiple sets of fields like these for identifying incoming and outgoing edges, it's possible to model many independent Directed Graphs that contain some or all of the documents in your collection. +The Document & Field modeling used in the above examples enumerated all of the outgoing and income edges for each node explicitly, to help demonstrate exactly how the "from" and "to" parameters work, and to give you an idea of what is possible. With multiple sets of fields like these for identifying incoming and outgoing edges, it's possible to model many independent Directed Graphs that contain some or all of the documents in your collection. But in many cases it can also be possible to drastically simplify the model used. -For example, the same graph shown in the diagram above can be modelled by Solr Documents that represent each node and know only the ids of the nodes they link to, without knowing anything about the incoming links: +For example, the same graph shown in the diagram above can be modeled by Solr Documents that represent each node and know only the ids of the nodes they link to, without knowing anything about the incoming links: [source,bash] ---- @@ -927,7 +927,7 @@ In the examples below, the result of each query is "XXX": {!switch case=XXX case.bar=zzz case.yak=qqq} ---- -A practical usage of this `QParserPlugin`, is in specifying `appends` fq params in the configuration of a SearchHandler, to provide a fixed set of filter options for clients using custom parameter names. +A practical usage of this parser, is in specifying `appends` filter query (`fq`) parameters in the configuration of a SearchHandler, to provide a fixed set of filter options for clients using custom parameter names. Using the example configuration below, clients can optionally specify the custom parameters `in_stock` and `shipping` to override the default filtering behavior, but are limited to the specific set of legal values (shipping=any|free, in_stock=yes|no|all). diff --git a/solr/solr-ref-guide/src/pagination-of-results.adoc b/solr/solr-ref-guide/src/pagination-of-results.adoc index f3deac7a993..f0b0fb6e045 100644 --- a/solr/solr-ref-guide/src/pagination-of-results.adoc +++ b/solr/solr-ref-guide/src/pagination-of-results.adoc @@ -98,7 +98,7 @@ There are a few important constraints to be aware of when using `cursorMark` par . `cursorMark` and `start` are mutually exclusive parameters. * Your requests must either not include a `start` parameter, or it must be specified with a value of "```0```". . `sort` clauses must include the uniqueKey field (either `asc` or `desc`). -* If `id` is your uniqueKey field, then sort params like `id asc` and `name asc, id desc` would both work fine, but `name asc` by itself would not +* If `id` is your uniqueKey field, then sort parameters like `id asc` and `name asc, id desc` would both work fine, but `name asc` by itself would not . Sorts including <> based functions that involve calculations relative to `NOW` will cause confusing results, since every document will get a new sort value on every subsequent request. This can easily result in cursors that never end, and constantly return the same documents over and over – even if the documents are never updated. + In this situation, choose & re-use a fixed value for the <> in all of your cursor requests. diff --git a/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc b/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc index 60cd60f4791..04dc84078df 100644 --- a/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc +++ b/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc @@ -16,8 +16,8 @@ // specific language governing permissions and limitations // under the License. -Solr components can be configured using *resources*: data stored in external files that may be referred to in a location-independent fashion. Examples include: files needed by schema components, e.g. a stopword list for <>; and machine-learned models for <>. - +Solr components can be configured using *resources*: data stored in external files that may be referred to in a location-independent fashion. Examples include: files needed by schema components, e.g., a stopword list for <>; and machine-learned models for <>. + Solr *plugins*, which can be configured in `solrconfig.xml`, are Java classes that are normally packaged in `.jar` files along with supporting classes and data. Solr ships with a number of built-in plugins, and can also be configured to use custom plugins. Example plugins are the <> and custom search components. Resources and plugins may be stored: @@ -25,29 +25,29 @@ Resources and plugins may be stored: * in ZooKeeper under a collection's configset node (SolrCloud only); * on a filesystem accessible to Solr nodes; or * in Solr's <> (SolrCloud only). - -NOTE: Schema components may not be stored as plugins in the Blob Store, and cannot access resources stored in the Blob Store. -== Resource and Plugin Loading Sequence +NOTE: Schema components may not be stored as plugins in the Blob Store, and cannot access resources stored in the Blob Store. + +== Resource and Plugin Loading Sequence Under SolrCloud, resources and plugins to be loaded are first looked up in ZooKeeper under the collection's configset znode. If the resource or plugin is not found there, Solr will fall back to loading <>. -Note that by default, Solr will not attempt to load resources and plugins from the Blob Store. To enable this, see the section <>. When loading from the Blob Store is enabled for a component, lookups occur only in the Blob Store, and never in ZooKeeper or on the filesystem. +Note that by default, Solr will not attempt to load resources and plugins from the Blob Store. To enable this, see the section <>. When loading from the Blob Store is enabled for a component, lookups occur only in the Blob Store, and never in ZooKeeper or on the filesystem. == Resources and Plugins in ConfigSets on ZooKeeper Resources and plugins may be uploaded to ZooKeeper as part of a configset, either via the <> or <>. -To upload a plugin or resource to a configset already stored on ZooKeeper, you can use <>. +To upload a plugin or resource to a configset already stored on ZooKeeper, you can use <>. CAUTION: By default, ZooKeeper's file size limit is 1MB. If your files are larger than this, you'll need to either <> or store them instead <>. - -== Resources and Plugins on the Filesystem + +== Resources and Plugins on the Filesystem Under standalone Solr, when looking up a plugin or resource to be loaded, Solr's resource loader will first look under the `/conf/` directory. If the plugin or resource is not found, the configured plugin and resource file paths are searched - see the section <> below. On core load, Solr's resource loader constructs a list of paths (subdirectories and jars), first under <>, and then under directories pointed to by <` directives in SolrConfig>>. - + When looking up a resource or plugin to be loaded, the paths on the list are searched in the order they were added. NOTE: Under SolrCloud, each node hosting a collection replica will need its own copy of plugins and resources to be loaded. @@ -58,7 +58,7 @@ WARNING: Resource files *will not be loaded* if they are located directly under === solr_home/lib -Each Solr node can have a directory named `lib/` under the <>. In order to use this directory to host resources or plugins, it must first be manually created. +Each Solr node can have a directory named `lib/` under the <>. In order to use this directory to host resources or plugins, it must first be manually created. === Lib Directives in SolrConfig @@ -68,7 +68,7 @@ Loading occurs in the order `` directives appear in `solrconfig.xml`. If t A regular expression supplied in the `` element's `regex` attribute value can be used to restrict which subdirectories and/or jar files are added to the Solr resource loader's list of search locations. If no regular expression is given, all direct subdirectory and jar children are included in the resource path list. All directories are resolved as relative to the Solr core's `instanceDir`. -From an example SolrConfig: +From an example SolrConfig: [source,xml] ---- diff --git a/solr/solr-ref-guide/src/rule-based-replica-placement.adoc b/solr/solr-ref-guide/src/rule-based-replica-placement.adoc index 66b1d459e5a..5dbd170e5e6 100644 --- a/solr/solr-ref-guide/src/rule-based-replica-placement.adoc +++ b/solr/solr-ref-guide/src/rule-based-replica-placement.adoc @@ -167,7 +167,7 @@ host:!192.45.67.3 == Defining Rules -Rules are specified per collection during collection creation as request parameters. It is possible to specify multiple ‘rule’ and ‘snitch’ params as in this example: +Rules are specified per collection during collection creation as request parameters. It is possible to specify multiple ‘rule’ and ‘snitch’ parameters as in this example: [source,text] ---- diff --git a/solr/solr-ref-guide/src/spell-checking.adoc b/solr/solr-ref-guide/src/spell-checking.adoc index 7911b84d2c1..c883ed93968 100644 --- a/solr/solr-ref-guide/src/spell-checking.adoc +++ b/solr/solr-ref-guide/src/spell-checking.adoc @@ -233,7 +233,7 @@ This parameter specifies the maximum number of documents that should be collecte 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. +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 parameters 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. `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. diff --git a/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc b/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc index 36f64e1a362..7f7e58b02f6 100644 --- a/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc +++ b/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc @@ -903,7 +903,7 @@ It is possible to send any JSON to the `/update/json/docs` endpoint and the defa ---- -So, if no params are passed, the entire JSON file would get indexed to the `\_src_` field and all the values in the input JSON would go to a field named `text`. If there is a value for the uniqueKey it is stored and if no value could be obtained from the input JSON, a UUID is created and used as the uniqueKey field value. +So, if no parameters are passed, the entire JSON file would get indexed to the `\_src_` field and all the values in the input JSON would go to a field named `text`. If there is a value for the uniqueKey it is stored and if no value could be obtained from the input JSON, a UUID is created and used as the uniqueKey field value. Alternately, use the Request Parameters feature to set these parameters, as shown earlier in the section <>.