You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@solr.apache.org by ep...@apache.org on 2024/02/06 22:03:08 UTC

(solr) branch branch_9x updated: fix a few typos in the Indexing Guide (#2245)

This is an automated email from the ASF dual-hosted git repository.

epugh pushed a commit to branch branch_9x
in repository https://gitbox.apache.org/repos/asf/solr.git


The following commit(s) were added to refs/heads/branch_9x by this push:
     new 633c299a5df fix a few typos in the Indexing Guide (#2245)
633c299a5df is described below

commit 633c299a5dfd2eaa1f69adba2eab76bb1941d02a
Author: Andrey Bozhko <an...@gmail.com>
AuthorDate: Tue Feb 6 16:02:05 2024 -0600

    fix a few typos in the Indexing Guide (#2245)
    
    Co-authored-by: Andrey Bozhko <ab...@apple.com>
---
 .../indexing-guide/pages/date-formatting-math.adoc     |  2 +-
 .../modules/indexing-guide/pages/documents-screen.adoc |  2 +-
 .../pages/field-types-included-with-solr.adoc          |  2 +-
 .../pages/indexing-nested-documents.adoc               | 18 +++++++++---------
 .../indexing-guide/pages/indexing-with-cbor.adoc       |  2 +-
 .../indexing-guide/pages/partial-document-updates.adoc |  6 +++---
 6 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/date-formatting-math.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/date-formatting-math.adoc
index 8da05250ad9..f8b2c1c9317 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/date-formatting-math.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/date-formatting-math.adoc
@@ -217,4 +217,4 @@ Unlike most local params, `op` is actually _not_ defined by any query parser (`f
 In the above example, it would find documents with indexed ranges that _contain_ (or equals) the range 2013 thru 2018.
 Multi-valued overlapping indexed ranges in a document are effectively coalesced.
 
-For a DateRangeField example use-case, see https://cwiki.apache.org/confluence/display/solr/DateRangeField[see Solr's community wiki].
+For a DateRangeField example use-case, see https://cwiki.apache.org/confluence/display/solr/DateRangeField[Solr's community wiki].
diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/documents-screen.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/documents-screen.adoc
index df17fbf7371..f5ce001a529 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/documents-screen.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/documents-screen.adoc
@@ -78,7 +78,7 @@ More information can be found in xref:indexing-with-tika.adoc[].
 
 == Solr Command
 
-The Solr Command option allows you use the `/update` request handler with XML or JSON formatted commands to perform specific actions.
+The Solr Command option allows you to use the `/update` request handler with XML or JSON formatted commands to perform specific actions.
 A few examples are:
 
 * Deleting documents
diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/field-types-included-with-solr.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/field-types-included-with-solr.adoc
index c5d429a572f..fa4e8855258 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/field-types-included-with-solr.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/field-types-included-with-solr.adoc
@@ -57,7 +57,7 @@ The {solr-javadocs}/core/org/apache/solr/schema/package-summary.html[`org.apache
 
 |LongPointField |Long field (64-bit signed integer). This class encodes foo values using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. For single valued fields, `docValues="true"` must be used to enable sorting.
 
-|NestPathField | Specialized field type storing ehanced information, when xref:indexing-nested-documents.adoc#schema-configuration[working with nested documents].
+|NestPathField | Specialized field type storing enhanced information, when xref:indexing-nested-documents.adoc#schema-configuration[working with nested documents].
 
 |PointType |A single-valued n-dimensional point. It's both for sorting spatial data that is _not_ lat-lon, and for some more rare use-cases. (NOTE: this is _not_ related to the "Point" based numeric fields). See xref:query-guide:spatial-search.adoc[] for more information.
 
diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-nested-documents.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-nested-documents.adoc
index 94c66c7d007..43347c59c28 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-nested-documents.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-nested-documents.adoc
@@ -21,8 +21,8 @@ Solr supports indexing nested documents, described here, and ways to xref:query-
 By way of examples: nested documents in Solr can be used to bind a blog post (parent document) with comments (child documents) -- or as a way to model major product lines as parent documents,
 with multiple types of child documents representing individual SKUs (with unique sizes / colors) and supporting documentation (either directly nested under the products, or under individual SKUs.
 
-The "top most" parent with all children is referred to as a "root" document or formerly "block
-document" and it explains some of the nomenclature of related features.
+The "top most" parent with all children is referred to as a "root" document (or formerly "block
+document"), and it explains some of the nomenclature of related features.
 
 At query time, the xref:query-guide:block-join-query-parser.adoc[] can search these relationships, and the xref:query-guide:document-transformers.adoc#child-childdoctransformerfactory[`[child]`] Document Transformer can attach child (or other "descendent") documents to the result documents.
 In terms of performance, indexing the relationships between documents usually yields much faster queries than an equivalent xref:query-guide:join-query-parser.adoc["query time join"],
@@ -57,7 +57,7 @@ There is no "child document" field type.
 ====
 
 //
-// DO NOT MODIFY THESE EXAMPLE DOCS WITH OUT REVIEWING ALL PAGES THAT INCLUDE/REFER BACK TO THESE EXAMPLES
+// DO NOT MODIFY THESE EXAMPLE DOCS WITHOUT REVIEWING ALL PAGES THAT INCLUDE/REFER BACK TO THESE EXAMPLES
 // INCLUDING THE SEMI-EQUIVALENT ANONYMOUS CHILDREN EXAMPLE AT THE BOTTOM OF THIS PAGE
 //
 [.dynamic-tabs]
@@ -232,7 +232,7 @@ Indexing nested documents _requires_ an indexed field named `\_root_`:
 xref:reindexing.adoc#changes-that-require-reindex[You must reindex].*
 
 * Solr automatically populates this field in _all_ documents with the `id` value of it's root document
--- it's highest ancestor, possibly itself.
+-- its highest ancestor, possibly itself.
 * This field must be indexed (`indexed="true"`) but doesn't need to
 be either stored (`stored="true"`) or use doc values (`docValues="true"`), however you are free to do so if you find it useful.
 If you want to use `uniqueBlock(\_root_)` xref:query-guide:json-facet-api#stat-facet-functions[field type limitation], then you should enable docValues.
@@ -285,20 +285,20 @@ xref:partial-document-updates.adoc#updating-child-documents[atomic updates] to i
 == Maintaining Integrity with Updates and Deletes
 
 Nested document trees can be modified with
-xref:partial-document-updates.adoc#atomic-updates,atomic updates>> to
+xref:partial-document-updates.adoc#atomic-updates[atomic updates] to
 manipulate any document in a nested tree, and even to add new child documents.
-This aspect isn't different than updating any normal document -- Solr internally deletes the old
-nested document tree and it adds the newly modified one.
+This aspect isn't different from updating any normal document -- Solr internally deletes the old
+nested document tree and adds the newly modified one.
 Just be mindful to add a `_root_` field if the partial update is to a child doc so that Solr
 knows which Root doc it's related to.
 
 Solr demands that the `id` of _all_ documents in a collection be unique.
-Solr enforces this for root documents within a shard but it doesn't for child documents to avoid the expense of checking.
+Solr enforces this for root documents within a shard, but not for child documents to avoid the expense of checking.
 Clients should be very careful to *never* violate this.
 
 To delete an entire nested document tree, you can simply delete-by-ID using the `id` of the root document.
 Delete-by-ID will not work with the `id` of a child document, since only root document IDs are considered.
-Instead, use delete-by-query (most efficient) or xref:partial-document-updates.adoc#atomic-updates[atomic updates] to remove the child document from it's parent.
+Instead, use delete-by-query (most efficient) or xref:partial-document-updates.adoc#atomic-updates[atomic updates] to remove the child document from its parent.
 
 If you use Solr's delete-by-query APIs, you *MUST* be careful to ensure that any deletion query is structured to ensure no descendent children remain of any documents that are being deleted.
 *_Doing otherwise will violate integrity assumptions that Solr expects._*
diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-with-cbor.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-with-cbor.adoc
index 54d69ef8845..0d15b4f01c1 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-with-cbor.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/indexing-with-cbor.adoc
@@ -94,7 +94,7 @@ else:
 
 == Node.js example
 
-Save the following program into a a file called `script.js`
+Save the following program into a file called `script.js`
 
 [,javascript]
 ----
diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/partial-document-updates.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/partial-document-updates.adoc
index 133ecca935e..1caa5f66d5a 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/partial-document-updates.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/partial-document-updates.adoc
@@ -62,7 +62,7 @@ May be specified as a single value, or as a list.
 
 `inc`::
 Increments or decrements a numeric field's value by a specific amount, specified as a single integer or float.
-Postive amounts increment the field's value, and negative decrement.
+Positive amounts increment the field's value, and negative decrement.
 
 === Field Storage
 
@@ -494,7 +494,7 @@ The basic usage of `DocBasedVersionConstraintsProcessorFactory` is to configure
 ----
 
 Note that `versionField` is a comma-delimited list of fields to check for version numbers.
-Once configured, this update processor will reject (HTTP error code 409) any attempt to update an existing document where the value of the `my_version_l` field in the "new" document is not greater then the value of that field in the existing document.
+Once configured, this update processor will reject (HTTP error code 409) any attempt to update an existing document where the value of the `my_version_l` field in the "new" document is not greater than the value of that field in the existing document.
 
 .versionField vs `\_version_`
 [IMPORTANT]
@@ -523,7 +523,7 @@ If set to `true`, the update will be silently ignored (and return a status 200 t
 +
 A String parameter that can be specified to indicate that this processor should also inspect Delete By Id commands.
 +
-The value of this option should be the name of a request parameter that the processor will consider mandatory for all attempts to Delete By Id, and must be be used by clients to specify a value for the `versionField` which is greater then the existing value of the document to be deleted.
+The value of this option should be the name of a request parameter that the processor will consider mandatory for all attempts to Delete By Id, and must be used by clients to specify a value for the `versionField` which is greater than the existing value of the document to be deleted.
 +
 When using this request parameter, any Delete By Id command with a high enough document version number to succeed will be internally converted into an Add Document command that replaces the existing document with a new one which is empty except for the Unique Key and `versionField` to keeping a record of the deleted version so future Add Document commands will fail if their "new" version is not high enough.
 +