SOLR-14241: fix typos & incorrect example param

This commit is contained in:
Cassandra Targett 2020-03-02 16:52:37 -06:00
parent 1f549dc474
commit f2a6ff1494
1 changed files with 5 additions and 5 deletions

View File

@ -597,7 +597,7 @@ daemonStream.close();
== delete
The `delete` function wraps another functions and uses the `id` and `\_version_` values found to sends the tuples to a SolrCloud collection as <<uploading-data-with-index-handlers.adoc#delete-operations,Delete By Id>> commands.
The `delete` function wraps other functions and uses the `id` and `\_version_` values found to send the tuples to a SolrCloud collection as <<uploading-data-with-index-handlers.adoc#delete-operations,Delete By Id>> commands.
This is similar to the `<<#update,update()>>` function described below.
@ -605,7 +605,7 @@ This is similar to the `<<#update,update()>>` function described below.
* `destinationCollection`: (Mandatory) The collection where the tuples will deleted.
* `batchSize`: (Mandatory) The indexing batch size.
* `pruneVersionField`: (Optional, defaults to `false`) Wether to prune `\_version_` values from tuples
* `pruneVersionField`: (Optional, defaults to `false`) Whether to prune `\_version_` values from tuples
* `StreamExpression`: (Mandatory)
=== delete Syntax
@ -626,11 +626,11 @@ The example above consumes the tuples returned by the `search` function against
[NOTE]
====
Unlike the `update()` function, `delete()` defaults to `pruneVersionField=false` -- preserving any `\_version_` values found in the inner stream when converting the tuples to "Delete By ID" requests, to ensure that using this stream will not (by default) result in deleting any documents that were updated _after_ the `search(...)` was executed, but _before_ the `delete(...)` processed that tuple (leveraging <<updating-parts-of-documents.adoc#optimistic-concurrency,Optimistic concurrency>> constraints).
Unlike the `update()` function, `delete()` defaults to `pruneVersionField=false` -- preserving any `\_version_` values found in the inner stream when converting the tuples to "Delete By ID" requests. This ensures that using this stream will not (by default) result in deleting any documents that were updated _after_ the `search(...)` was executed, but _before_ the `delete(...)` processed that tuple (leveraging <<updating-parts-of-documents.adoc#optimistic-concurrency,Optimistic concurrency>> constraints).
Users who wish to ignore concurrent updates, and delete all matched documents should set `pruneVersionField=false` (or ensure that the inner stream tuples do not include any `\_version_` values).
Users who wish to ignore concurrent updates and delete all matched documents should set `pruneVersionField=true` (or ensure that the inner stream tuples do not include any `\_version_` values).
Users who anticipate concurrent updates, and wish to "skip" any failed deletes, should consider configuraing the {solr-javadocs}/solr-core/org/apache/solr/update/processor/TolerantUpdateProcessorFactory.html[`TolerantUpdateProcessorFactory`]
Users who anticipate concurrent updates, and wish to "skip" any failed deletes, should consider configuring the {solr-javadocs}/solr-core/org/apache/solr/update/processor/TolerantUpdateProcessorFactory.html[`TolerantUpdateProcessorFactory`]
====