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 <[email protected]>
AuthorDate: Tue Feb 6 16:02:05 2024 -0600
fix a few typos in the Indexing Guide (#2245)
Co-authored-by: Andrey Bozhko <[email protected]>
---
.../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.
+
