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 2021/08/11 19:27:32 UTC
[lucene-solr] branch branch_8x updated: SOLR-15230 & SOLR-15495,
plus misc typos, duplicated words, etc.
This is an automated email from the ASF dual-hosted git repository.
ctargett pushed a commit to branch branch_8x
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
The following commit(s) were added to refs/heads/branch_8x by this push:
new 834d666 SOLR-15230 & SOLR-15495, plus misc typos, duplicated words, etc.
834d666 is described below
commit 834d6668d5ab68427a20427ac078f9c74d82eedf
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Wed Aug 11 14:26:09 2021 -0500
SOLR-15230 & SOLR-15495, plus misc typos, duplicated words, etc.
---
solr/solr-ref-guide/src/about-this-guide.adoc | 4 ++--
solr/solr-ref-guide/src/aliases.adoc | 2 +-
solr/solr-ref-guide/src/analytics.adoc | 2 +-
solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc | 2 +-
solr/solr-ref-guide/src/cdcr-config.adoc | 2 +-
solr/solr-ref-guide/src/cluster-node-management.adoc | 10 ++++++++++
solr/solr-ref-guide/src/collapse-and-expand-results.adoc | 2 +-
solr/solr-ref-guide/src/collection-management.adoc | 2 +-
solr/solr-ref-guide/src/common-query-parameters.adoc | 2 +-
solr/solr-ref-guide/src/defining-fields.adoc | 2 +-
solr/solr-ref-guide/src/logs.adoc | 2 +-
.../src/major-changes-from-solr-5-to-solr-6.adoc | 2 +-
solr/solr-ref-guide/src/near-real-time-searching.adoc | 2 +-
solr/solr-ref-guide/src/result-grouping.adoc | 2 +-
solr/solr-ref-guide/src/schema-api.adoc | 12 +-----------
solr/solr-ref-guide/src/search-sample.adoc | 6 +++---
solr/solr-ref-guide/src/segments-info.adoc | 2 +-
solr/solr-ref-guide/src/solr-tutorial.adoc | 4 ++--
solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc | 4 +++-
.../src/solrcloud-autoscaling-auto-add-replicas.adoc | 4 +++-
.../src/solrcloud-autoscaling-fault-tolerance.adoc | 4 +++-
solr/solr-ref-guide/src/solrcloud-autoscaling-listeners.adoc | 4 +++-
solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc | 2 +-
.../src/solrcloud-autoscaling-policy-preferences.adoc | 2 +-
.../src/solrcloud-autoscaling-trigger-actions.adoc | 4 +++-
solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc | 4 +++-
solr/solr-ref-guide/src/solrcloud-autoscaling.adoc | 2 +-
.../src/solrcloud-recoveries-and-write-tolerance.adoc | 2 +-
solr/solr-ref-guide/src/statistics.adoc | 2 +-
solr/solr-ref-guide/src/stream-evaluator-reference.adoc | 2 +-
solr/solr-ref-guide/src/stream-source-reference.adoc | 2 +-
solr/solr-ref-guide/src/the-query-elevation-component.adoc | 2 +-
solr/solr-ref-guide/src/the-term-vector-component.adoc | 4 ++--
.../src/transforming-and-indexing-custom-json.adoc | 2 +-
solr/solr-ref-guide/src/update-request-processors.adoc | 6 +++---
solr/solr-ref-guide/src/working-with-dates.adoc | 2 +-
36 files changed, 64 insertions(+), 52 deletions(-)
diff --git a/solr/solr-ref-guide/src/about-this-guide.adoc b/solr/solr-ref-guide/src/about-this-guide.adoc
index 0eff937..b819677 100644
--- a/solr/solr-ref-guide/src/about-this-guide.adoc
+++ b/solr/solr-ref-guide/src/about-this-guide.adoc
@@ -44,9 +44,9 @@ There are several items in this URL you might need to change locally. First, if
Path information is given relative to `solr.home`, which is the location under the main Solr installation where Solr's collections and their `conf` and `data` directories are stored.
-In many cases, this is is in the `server/solr` directory of your installation. However, there can be exceptions, particularly if your installation has customized this.
+In many cases, this is in the `server/solr` directory of your installation. However, there can be exceptions, particularly if your installation has customized this.
-In several cases of this Guide, our examples are built from the the "techproducts" example (i.e., you have started Solr with the command `bin/solr -e techproducts`). In this case, `solr.home` will be a sub-directory of the `example/` directory created for you automatically.
+In several cases of this Guide, our examples are built from the "techproducts" example (i.e., you have started Solr with the command `bin/solr -e techproducts`). In this case, `solr.home` will be a sub-directory of the `example/` directory created for you automatically.
See also the section <<solr-configuration-files.adoc#solr-home,Solr Home>> for further details on what is contained in this directory.
diff --git a/solr/solr-ref-guide/src/aliases.adoc b/solr/solr-ref-guide/src/aliases.adoc
index c83abc2..5d48711 100644
--- a/solr/solr-ref-guide/src/aliases.adoc
+++ b/solr/solr-ref-guide/src/aliases.adoc
@@ -283,7 +283,7 @@ As with all Routed Aliases, DRA's impose some costs if your data is not well beh
normal caveats of each component dimension there is a need for care in sending new categories after the DRA has been
running for a while. Ordered Dimensions (time) behave slightly differently from Unordered (category) dimensions.
Ordered dimensions rely on the iteration order of the collections in the alias and therefore cannot tolerate the
-generation of collection names out of order. The this means that of this is that when an ordered dimension such as time
+generation of collection names out of order. This means that of this is that when an ordered dimension such as time
is a component of a DRA and the DRA experiences receipt of a document with a novel category with a time value
corresponding to a time slice other than the starting time-slice for the time dimension, several collections will
need to be created before the document can be indexed. This "new category effect" is identical to the behavior
diff --git a/solr/solr-ref-guide/src/analytics.adoc b/solr/solr-ref-guide/src/analytics.adoc
index 76b7ebf..fbf1994 100644
--- a/solr/solr-ref-guide/src/analytics.adoc
+++ b/solr/solr-ref-guide/src/analytics.adoc
@@ -60,7 +60,7 @@ An Analytics request is passed to Solr with the parameter `analytics` in a reque
<<requesthandlers-and-searchcomponents-in-solrconfig.adoc#searchhandlers,Search Handler>>.
Since the analytics request is sent inside of a search handler request, it will compute results based on the result set determined by the search handler.
-For example, this curl command encodes and POSTs a simple analytics request to the the search handler:
+For example, this curl command encodes and POSTs a simple analytics request to the search handler:
[source,bash]
----
diff --git a/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc b/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc
index 325def6..4b6fb01 100644
--- a/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc
+++ b/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc
@@ -243,7 +243,7 @@ $ cd $ZOO_HOME
$ bin/zkServer.sh start
----
-. On the the first node being used for Solr (`solr-node-1`), start Solr and tell it where to find ZooKeeper.
+. On the first node being used for Solr (`solr-node-1`), start Solr and tell it where to find ZooKeeper.
+
[source,bash]
----
diff --git a/solr/solr-ref-guide/src/cdcr-config.adoc b/solr/solr-ref-guide/src/cdcr-config.adoc
index 1099fb8..b692d66 100644
--- a/solr/solr-ref-guide/src/cdcr-config.adoc
+++ b/solr/solr-ref-guide/src/cdcr-config.adoc
@@ -335,7 +335,7 @@ Based on the same example from uni-directional solution, let's walk through the
* Before you begin, stop or pause any indexing processes. This is best done during a small maintenance window.
* Stop the SolrCloud instances in both Cluster 1 and Cluster 2.
* Upload the modified `solrconfig.xml` to ZooKeeper on both Cluster 1 and Cluster 2 as appropriate, see the examples above in the section <<Bi-Directional Updates>>.
-* If documents were indexed prior to this exercise, sync the index directories from the Cluster 1 collection to the Cluster 2 collection to the corresponding shard nodes or vice versa. The `rsync` utility works well for this if it's available on your server. Check to be sure the the updated index is copied across.
+* If documents were indexed prior to this exercise, sync the index directories from the Cluster 1 collection to the Cluster 2 collection to the corresponding shard nodes or vice versa. The `rsync` utility works well for this if it's available on your server. Check to be sure the updated index is copied across.
+
For example, if there are 2 shards on collection 'cluster1' (the updated collection) with 2 replicas for each shard, copy the corresponding index directories from:
+
diff --git a/solr/solr-ref-guide/src/cluster-node-management.adoc b/solr/solr-ref-guide/src/cluster-node-management.adoc
index baa1ea8..a4a3902 100644
--- a/solr/solr-ref-guide/src/cluster-node-management.adoc
+++ b/solr/solr-ref-guide/src/cluster-node-management.adoc
@@ -310,6 +310,16 @@ Examining the clusterstate after issuing this call should show exactly one repli
[[utilizenode]]
== UTILIZENODE: Utilize a New Node
+[WARNING]
+.Autoscaling is deprecated
+====
+The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
+
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+This command is part of the autoscaling framework and will be removed in 9.0 without a replacement.
+====
+
This command can be used to move some replicas from the existing nodes to either a new node or a less loaded node to reduce the load on the existing node.
This uses your autoscaling policies and preferences to identify which replica needs to be moved. It tries to fix any policy violations first and then it tries to move some load off of the most loaded nodes according to the preferences.
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 6f32487..2210d32 100644
--- a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
+++ b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
@@ -150,7 +150,7 @@ This more efficient logic can also be used with other `collapseField` values, vi
====
Specifing `hint=block` when collapsing on a field that is not unique per contiguous block of documents is not supported and may fail in unexpected ways; including the possibility of silently returning incorrect results.
-The implementation does not offer any safeguards against misuse on an unsupported field, since doing so would require the the same group level tracking as the non-Block collapsing implementation -- defeating the purpose of this optimization.
+The implementation does not offer any safeguards against misuse on an unsupported field, since doing so would require the same group level tracking as the non-Block collapsing implementation -- defeating the purpose of this optimization.
====
== Expand Component
diff --git a/solr/solr-ref-guide/src/collection-management.adoc b/solr/solr-ref-guide/src/collection-management.adoc
index c0ddbe9..f558d20 100644
--- a/solr/solr-ref-guide/src/collection-management.adoc
+++ b/solr/solr-ref-guide/src/collection-management.adoc
@@ -1463,7 +1463,7 @@ See the parameter descriptions below for more information.
*Input*
-The following API command deletes the the first backup (`backupId=0`) at the specified repository location.
+The following API command deletes the first backup (`backupId=0`) at the specified repository location.
[.dynamic-tabs]
--
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
index eee5de6..246c355 100644
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -39,7 +39,7 @@ Solr can sort query responses according to:
* The value of any primitive field (numerics, string, boolean, dates, etc.) which has `docValues="true"` (or `multiValued="false"` and `indexed="true"`, in which case the indexed terms will used to build DocValue like structures on the fly at runtime)
* A SortableTextField which implicitly uses `docValues="true"` by default to allow sorting on the original input string regardless of the analyzers used for Searching.
* A single-valued TextField that uses an analyzer (such as the KeywordTokenizer) that produces only a single term per document. TextField does not support `docValues="true"`, but a DocValue-like structure will be built on the fly at runtime.
-** *NOTE:* If you want to be able to sort on a field whose contents you want to tokenize to facilitate searching, <<copying-fields.adoc#,use a `copyField` directive>> in the the Schema to clone the field. Then search on the field and sort on its clone.
+** *NOTE:* If you want to be able to sort on a field whose contents you want to tokenize to facilitate searching, <<copying-fields.adoc#,use a `copyField` directive>> in the Schema to clone the field. Then search on the field and sort on its clone.
In the case of primitive fields, or SortableTextFields, that are `multiValued="true"` the representative value used for each doc when sorting depends on the sort direction: The minimum value in each document is used for ascending (`asc`) sorting, while the maximal value in each document is used for descending (`desc`) sorting. This default behavior is equivalent to explicitly sorting using the 2 argument `<<function-queries.adoc#field-function,field()>>` function: `sort=field(name,min) [...]
diff --git a/solr/solr-ref-guide/src/defining-fields.adoc b/solr/solr-ref-guide/src/defining-fields.adoc
index 3a0c8ad..32aedb9 100644
--- a/solr/solr-ref-guide/src/defining-fields.adoc
+++ b/solr/solr-ref-guide/src/defining-fields.adoc
@@ -42,7 +42,7 @@ A default value that will be added automatically to any document that does not h
== Optional Field Type Override Properties
-Fields can have many of the same properties as field types. Properties from the table below which are specified on an individual field will override any explicit value for that property specified on the the `fieldType` of the field, or any implicit default property value provided by the underlying `fieldType` implementation. The table below is reproduced from <<field-type-definitions-and-properties.adoc#,Field Type Definitions and Properties>>, which has more details:
+Fields can have many of the same properties as field types. Properties from the table below which are specified on an individual field will override any explicit value for that property specified on the `fieldType` of the field, or any implicit default property value provided by the underlying `fieldType` implementation. The table below is reproduced from <<field-type-definitions-and-properties.adoc#,Field Type Definitions and Properties>>, which has more details:
// TODO: SOLR-10655 BEGIN: refactor this into a 'field-default-properties.include.adoc' file for reuse
diff --git a/solr/solr-ref-guide/src/logs.adoc b/solr/solr-ref-guide/src/logs.adoc
index e8dfc34..46f1934 100644
--- a/solr/solr-ref-guide/src/logs.adoc
+++ b/solr/solr-ref-guide/src/logs.adoc
@@ -68,7 +68,7 @@ parameter which is the name of the collection to sample.
image::images/math-expressions/logs-sample.png[]
-The sample contains 500 random records with the their full field list. By looking
+The sample contains 500 random records with their full field list. By looking
at this sample we can quickly learn about the *fields* available in the `logs` collection.
=== Time Period
diff --git a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
index 56eb40f..ad189cc 100644
--- a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
+++ b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
@@ -78,7 +78,7 @@ Please review the <<schema-factory-definition-in-solrconfig.adoc#,Schema Factory
Solr's default behavior when a Schema does not explicitly define a global <<other-schema-elements.adoc#,`<similarity/>`>> is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of `SchemaSimilarityFactory` will be used. Most notably this change means that users can take advantage of per Field Type similarity declarations, without needing to also explicit [...]
-Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimilarityFactory` 's implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the the `luceneMatchVersion`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Similarity` will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` d [...]
+Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimilarityFactory` 's implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the `luceneMatchVersion`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Similarity` will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` decla [...]
== Replica & Shard Delete Command Changes
diff --git a/solr/solr-ref-guide/src/near-real-time-searching.adoc b/solr/solr-ref-guide/src/near-real-time-searching.adoc
index ba453c8..76e85d3 100644
--- a/solr/solr-ref-guide/src/near-real-time-searching.adoc
+++ b/solr/solr-ref-guide/src/near-real-time-searching.adoc
@@ -79,7 +79,7 @@ TIP: These parameters can be overridden at run time by defining Java "system var
The choices for `autoCommit` (with `openSearcher=false`) and `autoSoftCommit` have different consequences. In the event of un-graceful shutdown, it can take up to the time specified in `autoCommit` for Solr to replay the uncommitted documents from the transaction log.
-The time chosen for `autoSoftCommit` determines the maximum time after a document is sent to Solr before it becomes searchable and does not affect the transaction log. Choose as long an interval as your application can tolerate for this value, often 15-60 seconds is reasonable, or even longer depending on the requirements. In situations where the the time is set to a very short interval (say 1 second), consider disabling your caches (queryResultCache and filterCache especially) as they w [...]
+The time chosen for `autoSoftCommit` determines the maximum time after a document is sent to Solr before it becomes searchable and does not affect the transaction log. Choose as long an interval as your application can tolerate for this value, often 15-60 seconds is reasonable, or even longer depending on the requirements. In situations where the time is set to a very short interval (say 1 second), consider disabling your caches (queryResultCache and filterCache especially) as they will [...]
TIP: For extremely high bulk indexing, especially for the initial load if there is no searching, consider turning off `autoSoftCommit` by specifying a value of `-1` for the maxTime parameter.
diff --git a/solr/solr-ref-guide/src/result-grouping.adoc b/solr/solr-ref-guide/src/result-grouping.adoc
index fb81148..078f767 100644
--- a/solr/solr-ref-guide/src/result-grouping.adoc
+++ b/solr/solr-ref-guide/src/result-grouping.adoc
@@ -266,5 +266,5 @@ In this case, Solr found five matches for "memory," but only returns four result
Grouping is supported for <<solrcloud.adoc#,distributed searches>>, with some caveats:
-* Currently `group.func` is is not supported in any distributed searches
+* Currently `group.func` is not supported in any distributed searches
* `group.ngroups` and `group.facet` require that all documents in each group must be co-located on the same shard in order for accurate counts to be returned. <<shards-and-indexing-data-in-solrcloud.adoc#,Document routing via composite keys>> can be a useful solution in many situations.
diff --git a/solr/solr-ref-guide/src/schema-api.adoc b/solr/solr-ref-guide/src/schema-api.adoc
index a1ac229..afc2c12 100644
--- a/solr/solr-ref-guide/src/schema-api.adoc
+++ b/solr/solr-ref-guide/src/schema-api.adoc
@@ -1035,24 +1035,14 @@ The sample output below has been truncated to show a few different field types f
}
},
"class": "solr.TextField",
- "dynamicFields": [],
- "fields": [],
"name": "alphaOnlySort",
"omitNorms": true,
"sortMissingLast": true
},
{
"class": "solr.FloatPointField",
- "dynamicFields": [
- "*_fs",
- "*_f"
- ],
- "fields": [
- "price",
- "weight"
- ],
"name": "float",
- "positionIncrementGap": "0",
+ "positionIncrementGap": "0"
}]
}
----
diff --git a/solr/solr-ref-guide/src/search-sample.adoc b/solr/solr-ref-guide/src/search-sample.adoc
index 7834e1d..2737415 100644
--- a/solr/solr-ref-guide/src/search-sample.adoc
+++ b/solr/solr-ref-guide/src/search-sample.adoc
@@ -100,7 +100,7 @@ distribution of the `filesize_d` variable:
* The sample seems to have a balanced number of observations above and below
40,000. Based on this the *mean* and *mode* would appear to be around 40,000.
* The number of observations tapers off to a small number of outliers on
-the and low and high end of the sample.
+the low and high end of the sample.
This sample can be re-run multiple times to see if the samples
produce similar plots.
@@ -219,8 +219,8 @@ The `timeseries` function supports any combination of the following aggregate fu
The `significantTerms` function queries a collection, but instead of returning documents, it returns significant terms found in documents in the result set.
This function scores terms based on how frequently they appear in the result set and how rarely they appear in the entire corpus.
The `significantTerms` function emits a tuple for each term which contains the term, the score, the foreground count and the background count.
-The foreground count is how many documents the term appears in in the result set.
-The background count is how many documents the term appears in in the entire corpus.
+The foreground count is how many documents the term appears in the result set.
+The background count is how many documents the term appears in the entire corpus.
The foreground and background counts are global for the collection.
The `significantTerms` function can often provide insights that cannot be gleaned from other types of aggregations.
diff --git a/solr/solr-ref-guide/src/segments-info.adoc b/solr/solr-ref-guide/src/segments-info.adoc
index 8e38dcb..c36d47b 100644
--- a/solr/solr-ref-guide/src/segments-info.adoc
+++ b/solr/solr-ref-guide/src/segments-info.adoc
@@ -16,7 +16,7 @@
// specific language governing permissions and limitations
// under the License.
-The Segments Info screen lets you see a visualization of the various segments in the underlying Lucene index for this core, with information about the size of each segment – both bytes and in number of documents – as well as other basic metadata about those segments. Most visible is the the number of deleted documents, but you can hover your mouse over the segments to see additional numeric details.
+The Segments Info screen lets you see a visualization of the various segments in the underlying Lucene index for this core, with information about the size of each segment – both bytes and in number of documents – as well as other basic metadata about those segments. Most visible is the number of deleted documents, but you can hover your mouse over the segments to see additional numeric details.
image::images/segments-info/segments_info.png[image,width=486,height=250]
diff --git a/solr/solr-ref-guide/src/solr-tutorial.adoc b/solr/solr-ref-guide/src/solr-tutorial.adoc
index 96ae38a..046819b 100644
--- a/solr/solr-ref-guide/src/solr-tutorial.adoc
+++ b/solr/solr-ref-guide/src/solr-tutorial.adoc
@@ -593,7 +593,7 @@ It is possible to mix schemaless features with a defined schema. Using the Schem
===== Create the "names" Field
The films data we are going to index has a small number of fields for each movie: an ID, director name(s), film name, release date, and genre(s).
-If you look at one of the files in `example/films`, you'll see the first film is named _.45_, released in 2006. As the first document in the dataset, Solr is going to guess the field type based on the data in the record. If we go ahead and index this data, that first film name is going to indicate to Solr that that field type is a "float" numeric field, and will create a "name" field with a type `FloatPointField`. All data after this record will be expected to be a float.
+If you look at one of the files in `example/films`, you'll see the first film is named _.45_, released in 2006. As the first document in the dataset, Solr is going to guess the field type based on the data in the record. If we go ahead and index this data, the first film name is going to indicate to Solr that the field type is a "float" numeric field, and will create a "name" field with a type `FloatPointField`. All data after this record will be expected to be a float.
Well, that's not going to work. We have titles like _A Mighty Wind_ and _Chicken Run_, which are strings - decidedly not numeric and not floats. If we let Solr guess the "name" field is a float, what will happen is later titles will cause an error and indexing will fail. That's not going to get us very far.
@@ -927,7 +927,7 @@ Use the Admin UI <<documents-screen.adoc#,Documents tab>> (at http://localhost:8
You may notice that even if you index content in this tutorial more than once, it does not duplicate the results found. This is because the example Solr schema (a file named either `managed-schema` or `schema.xml`) specifies a `uniqueKey` field called `id`. Whenever you POST commands to Solr to add a document with the same value for the `uniqueKey` as an existing document, it automatically replaces it for you.
-You can see that that has happened by looking at the values for `numDocs` and `maxDoc` in the core-specific Overview section of the Solr Admin UI.
+You can see that has happened by looking at the values for `numDocs` and `maxDoc` in the core-specific Overview section of the Solr Admin UI.
`numDocs` represents the number of searchable documents in the index (and will be larger than the number of XML, JSON, or CSV files since some files contained more than one document). The `maxDoc` value may be larger as the `maxDoc` count includes logically deleted documents that have not yet been physically removed from the index. You can re-post the sample files over and over again as much as you want and `numDocs` will never increase, because the new documents will constantly be repla [...]
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc
index e619c04..635347b 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc
@@ -22,7 +22,9 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+There is no planned replacement for the Autoscaling API.
====
The Autoscaling API is used to manage autoscaling policies, preferences, triggers, listeners and to get diagnostics on the state of the cluster.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-auto-add-replicas.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-auto-add-replicas.adoc
index 1426b7a..6621acf 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-auto-add-replicas.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-auto-add-replicas.adoc
@@ -21,7 +21,9 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+There is no planned replacement for autoAddReplicas.
====
Solr provides a way to automatically add replicas for a collection when the number of active replicas drops below
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-fault-tolerance.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-fault-tolerance.adoc
index 735a843..0d66234 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-fault-tolerance.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-fault-tolerance.adoc
@@ -21,7 +21,9 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+There is no planned replacement for the functionality described on this page.
====
The autoscaling framework uses a few strategies to ensure it's able to still trigger actions in the event of unexpected changes to the system.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-listeners.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-listeners.adoc
index 4743876..e24ad25 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-listeners.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-listeners.adoc
@@ -21,7 +21,9 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+There is no planned replacement for listeners.
====
Trigger Listeners allow users to configure additional behavior related to trigger events as they are being processed.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
index 02ef8ea..a407cf2 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
@@ -22,7 +22,7 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
====
Autoscaling in Solr aims to provide good defaults so a SolrCloud cluster remains balanced and stable in the face of various cluster change events. This balance is achieved by satisfying a set of rules and sorting preferences to select the target of cluster management operations automatically on cluster events.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
index 83f98d4..86a47c1 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
@@ -22,7 +22,7 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
====
The autoscaling policy and preferences are a set of rules and sorting preferences that help Solr select the target of cluster management operations so the overall load on the cluster remains balanced.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-trigger-actions.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-trigger-actions.adoc
index c0646ff..5fb169c 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-trigger-actions.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-trigger-actions.adoc
@@ -21,7 +21,9 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+There is no planned replacement for trigger actions.
====
`TriggerAction` implementations process events generated by triggers in order to ensure the cluster's
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc
index f631e8e..ffca042 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc
@@ -21,7 +21,9 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
+
+There is no planned replacement for triggers.
====
Triggers are used in autoscaling to watch for cluster events such as nodes joining or leaving, search rate, index rate, on a schedule, or any other metric breaching a threshold.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc
index 01baad1..ca1dbe4 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc
@@ -22,7 +22,7 @@
====
The autoscaling framework in its current form is deprecated and will be removed in Solr 9.0.
-A new design for this feature is currently under development in https://issues.apache.org/jira/browse/SOLR-14613[SOLR-14613] with a goal for release with Solr 9.0.
+Some features relating to replica placement will be replaced in 9.0, but other features are not likely to be replaced.
====
[.lead]
diff --git a/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc b/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc
index f515f87..80051b4 100644
--- a/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc
@@ -20,7 +20,7 @@ SolrCloud is highly available and fault tolerant in reads and writes.
== Write Side Fault Tolerance
-SolrCloud is designed to replicate documents to ensure redundancy for your data, and enable you to send update requests to any node in the cluster. That node will determine if it hosts the leader for the appropriate shard, and if not it will forward the request to the the leader, which will then forward it to all existing replicas, using versioning to make sure every replica has the most up-to-date version. If the leader goes down, another replica can take its place. This architecture en [...]
+SolrCloud is designed to replicate documents to ensure redundancy for your data, and enable you to send update requests to any node in the cluster. That node will determine if it hosts the leader for the appropriate shard, and if not it will forward the request to the leader, which will then forward it to all existing replicas, using versioning to make sure every replica has the most up-to-date version. If the leader goes down, another replica can take its place. This architecture enable [...]
=== Recovery
diff --git a/solr/solr-ref-guide/src/statistics.adoc b/solr/solr-ref-guide/src/statistics.adoc
index d391e4b..ffc02b7 100644
--- a/solr/solr-ref-guide/src/statistics.adoc
+++ b/solr/solr-ref-guide/src/statistics.adoc
@@ -197,7 +197,7 @@ Below is an example of a frequency table built from a result set
of rounded *differences* in daily opening stock prices for the stock ticker *amzn*.
This example is interesting because it shows a multi-step process to arrive
-at the result. The first step is to *search* for records in the the *stocks*
+at the result. The first step is to *search* for records in the *stocks*
collection with a ticker of *amzn*. Notice that the result set is sorted by
date ascending and it returns the `open_d` field which is the opening price for
the day.
diff --git a/solr/solr-ref-guide/src/stream-evaluator-reference.adoc b/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
index 44efd5d..8650b55 100644
--- a/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
+++ b/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
@@ -2271,7 +2271,7 @@ numeric: result of the sumSq calculation
== transpose
-The `transpose` function https://en.wikipedia.org/wiki/Transpose[transposes] a matrix .
+The `transpose` function https://en.wikipedia.org/wiki/Transpose[transposes] a matrix.
=== transpose Parameters
diff --git a/solr/solr-ref-guide/src/stream-source-reference.adoc b/solr/solr-ref-guide/src/stream-source-reference.adoc
index 8226499..e7f5fe1 100644
--- a/solr/solr-ref-guide/src/stream-source-reference.adoc
+++ b/solr/solr-ref-guide/src/stream-source-reference.adoc
@@ -387,7 +387,7 @@ In the example above the `random` function is searching the baskets collections
== significantTerms
-The `significantTerms` function queries a SolrCloud collection, but instead of returning documents, it returns significant terms found in documents in the result set. The `significantTerms` function scores terms based on how frequently they appear in the result set and how rarely they appear in the entire corpus. The `significantTerms` function emits a tuple for each term which contains the term, the score, the foreground count and the background count. The foreground count is how many d [...]
+The `significantTerms` function queries a SolrCloud collection, but instead of returning documents, it returns significant terms found in documents in the result set. The `significantTerms` function scores terms based on how frequently they appear in the result set and how rarely they appear in the entire corpus. The `significantTerms` function emits a tuple for each term which contains the term, the score, the foreground count and the background count. The foreground count is how many d [...]
=== significantTerms Parameters
diff --git a/solr/solr-ref-guide/src/the-query-elevation-component.adoc b/solr/solr-ref-guide/src/the-query-elevation-component.adoc
index 75b187b..026e233 100644
--- a/solr/solr-ref-guide/src/the-query-elevation-component.adoc
+++ b/solr/solr-ref-guide/src/the-query-elevation-component.adoc
@@ -180,7 +180,7 @@ For example, in the request below documents 3007WFP and 9885A004 will be elevate
[source,text]
http://localhost:8983/solr/techproducts/elevate?q=cable&df=text&excludeIds=IW-02&elevateIds=3007WFP,9885A004
-If either one of these parameters is specified at request time, the the entire elevation configuration for the query is ignored.
+If either one of these parameters is specified at request time, the entire elevation configuration for the query is ignored.
For example, in the request below documents IW-02 and F8V7067-APL-KIT will be elevated, and no documents will be excluded – regardless of what elevations or exclusions are configured for the query "ipod" in elevate.xml:
diff --git a/solr/solr-ref-guide/src/the-term-vector-component.adoc b/solr/solr-ref-guide/src/the-term-vector-component.adoc
index 3d88e37..fd5fe32 100644
--- a/solr/solr-ref-guide/src/the-term-vector-component.adoc
+++ b/solr/solr-ref-guide/src/the-term-vector-component.adoc
@@ -29,7 +29,7 @@ The TermVectorComponent is not enabled implicitly in Solr - it must be explicitl
bin/solr -e techproducts
----
-To enable the this component, you need to configure it using a `searchComponent` element:
+To enable this component, you need to configure it using a `searchComponent` element:
[source,xml]
----
@@ -156,7 +156,7 @@ If `true`, returns payload information.
If `true`, returns document term frequency info for each term in the document.
`tv.tf_idf`::
-If `true`, calculates TF / DF (i.e.,: TF * IDF) for each term. Please note that this is a _literal_ calculation of "Term Frequency multiplied by Inverse Document Frequency" and *not* a classical TF-IDF similarity measure.
+If `true`, calculates TF / DF (i.e., TF * IDF) for each term. Please note that this is a _literal_ calculation of "Term Frequency multiplied by Inverse Document Frequency" and *not* a classical TF-IDF similarity measure.
+
This parameter requires both `tv.tf` and `tv.df` to be "true". This can be computationally expensive. (The results are not shown in example output)
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 9bbea92..8b1f51c 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
@@ -793,7 +793,7 @@ It is possible to send any JSON to the `/update/json/docs` endpoint and the defa
<lst name="defaults">
<!-- this ensures that the entire JSON doc will be stored verbatim into one field -->
<str name="srcField">_src_</str>
- <!-- This means a the uniqueKeyField will be extracted from the fields and
+ <!-- This means the uniqueKeyField will be extracted from the fields and
all fields go into the 'df' field. In this config df is already configured to be 'text'
-->
<str name="mapUniqueKeyOnly">true</str>
diff --git a/solr/solr-ref-guide/src/update-request-processors.adoc b/solr/solr-ref-guide/src/update-request-processors.adoc
index 0af36fe..4d6a03a 100644
--- a/solr/solr-ref-guide/src/update-request-processors.adoc
+++ b/solr/solr-ref-guide/src/update-request-processors.adoc
@@ -299,7 +299,7 @@ These factories all provide functionality to _modify_ fields in a document as th
{solr-javadocs}/solr-core/org/apache/solr/update/processor/ConcatFieldUpdateProcessorFactory.html[ConcatFieldUpdateProcessorFactory]:: Concatenates multiple values for fields matching the specified conditions using a configurable delimiter.
-{solr-javadocs}/solr-core/org/apache/solr/update/processor/CountFieldValuesUpdateProcessorFactory.html[CountFieldValuesUpdateProcessorFactory]:: Replaces any list of values for a field matching the specified conditions with the the count of the number of values for that field.
+{solr-javadocs}/solr-core/org/apache/solr/update/processor/CountFieldValuesUpdateProcessorFactory.html[CountFieldValuesUpdateProcessorFactory]:: Replaces any list of values for a field matching the specified conditions with the count of the number of values for that field.
{solr-javadocs}/solr-core/org/apache/solr/update/processor/FieldLengthUpdateProcessorFactory.html[FieldLengthUpdateProcessorFactory]:: Replaces any CharSequence values found in fields matching the specified conditions with the lengths of those CharSequences (as an Integer).
@@ -311,9 +311,9 @@ These factories all provide functionality to _modify_ fields in a document as th
{solr-javadocs}/solr-core/org/apache/solr/update/processor/LastFieldValueUpdateProcessorFactory.html[LastFieldValueUpdateProcessorFactory]:: Keeps only the last value of fields matching the specified conditions.
-{solr-javadocs}/solr-core/org/apache/solr/update/processor/MaxFieldValueUpdateProcessorFactory.html[MaxFieldValueUpdateProcessorFactory]:: An update processor that keeps only the the maximum value from any selected fields where multiple values are found.
+{solr-javadocs}/solr-core/org/apache/solr/update/processor/MaxFieldValueUpdateProcessorFactory.html[MaxFieldValueUpdateProcessorFactory]:: An update processor that keeps only the maximum value from any selected fields where multiple values are found.
-{solr-javadocs}/solr-core/org/apache/solr/update/processor/MinFieldValueUpdateProcessorFactory.html[MinFieldValueUpdateProcessorFactory]:: An update processor that keeps only the the minimum value from any selected fields where multiple values are found.
+{solr-javadocs}/solr-core/org/apache/solr/update/processor/MinFieldValueUpdateProcessorFactory.html[MinFieldValueUpdateProcessorFactory]:: An update processor that keeps only the minimum value from any selected fields where multiple values are found.
{solr-javadocs}/solr-core/org/apache/solr/update/processor/ParseBooleanFieldUpdateProcessorFactory.html[ParseBooleanFieldUpdateProcessorFactory]:: Attempts to mutate selected fields that have only CharSequence-typed values into Boolean values.
diff --git a/solr/solr-ref-guide/src/working-with-dates.adoc b/solr/solr-ref-guide/src/working-with-dates.adoc
index 52d914b..d37c23c 100644
--- a/solr/solr-ref-guide/src/working-with-dates.adoc
+++ b/solr/solr-ref-guide/src/working-with-dates.adoc
@@ -101,7 +101,7 @@ Note that while date math is most commonly used relative to `NOW` it can be appl
==== NOW
-The `NOW` parameter is used internally by Solr to ensure consistent date math expression parsing across multiple nodes in a distributed request. But it can be specified to instruct Solr to use an arbitrary moment in time (past or future) to override for all situations where the the special value of "```NOW```" would impact date math expressions.
+The `NOW` parameter is used internally by Solr to ensure consistent date math expression parsing across multiple nodes in a distributed request. But it can be specified to instruct Solr to use an arbitrary moment in time (past or future) to override for all situations where the special value of `NOW` would impact date math expressions.
It must be specified as a (long valued) milliseconds since epoch.