You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by dw...@apache.org on 2021/03/10 09:59:28 UTC
[lucene] 15/50: SOLR-11509: Misc typo cleanup and copy edits for
7.1 Ref Guide
This is an automated email from the ASF dual-hosted git repository.
dweiss pushed a commit to branch branch_7_1
in repository https://gitbox.apache.org/repos/asf/lucene.git
commit bb9cf90b4d260da88b027936ab95c29daf668a19
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Thu Oct 19 15:03:59 2017 -0500
SOLR-11509: Misc typo cleanup and copy edits for 7.1 Ref Guide
---
...datadir-and-directoryfactory-in-solrconfig.adoc | 2 +-
solr/solr-ref-guide/src/other-parsers.adoc | 23 ++++++-----
.../src/requestdispatcher-in-solrconfig.adoc | 19 +++++----
.../src/solr-control-script-reference.adoc | 15 +++----
.../src/update-request-processors.adoc | 47 +++++++++++++---------
.../src/updatehandlers-in-solrconfig.adoc | 1 -
6 files changed, 60 insertions(+), 47 deletions(-)
diff --git a/solr/solr-ref-guide/src/datadir-and-directoryfactory-in-solrconfig.adoc b/solr/solr-ref-guide/src/datadir-and-directoryfactory-in-solrconfig.adoc
index d36d781..f4a6b9e 100644
--- a/solr/solr-ref-guide/src/datadir-and-directoryfactory-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/datadir-and-directoryfactory-in-solrconfig.adoc
@@ -38,7 +38,7 @@ element `<solrDataHome>` then the location of data directory will be `<SOLR_DATA
== Specifying the DirectoryFactory For Your Index
-The default {solr-javadocs}/solr-core/org/apache/solr/core/StandardDirectoryFactory.html[`solr.StandardDirectoryFactory`] is filesystem based, and tries to pick the best implementation for the current JVM and platform. You can force a particular implementation and/or config options by specifying {solr-javadocs}/solr-core/org/apache/solr/core/MMapDirectoryFactory.html[`solr.MMapDirectoryFactory`], {solr-javadocs}/solr-core/org/apache/solr/core/NIOFSDirectoryFactory.html[`solr.NIOFSDirecto [...]
+The default {solr-javadocs}/solr-core/org/apache/solr/core/NRTCachingDirectoryFactory.html[`solr.NRTCachingDirectoryFactory`] is filesystem based, and tries to pick the best implementation for the current JVM and platform. You can force a particular implementation and/or config options by specifying {solr-javadocs}/solr-core/org/apache/solr/core/MMapDirectoryFactory.html[`solr.MMapDirectoryFactory`], {solr-javadocs}/solr-core/org/apache/solr/core/NIOFSDirectoryFactory.html[`solr.NIOFSDir [...]
[source,xml]
----
diff --git a/solr/solr-ref-guide/src/other-parsers.adoc b/solr/solr-ref-guide/src/other-parsers.adoc
index eda5214..a9de108 100644
--- a/solr/solr-ref-guide/src/other-parsers.adoc
+++ b/solr/solr-ref-guide/src/other-parsers.adoc
@@ -337,9 +337,10 @@ The `graph` query parser does a breadth first, cyclic aware, graph traversal of
The graph is built according to linkages between documents based on the terms found in `from` and `to` fields that you specify as part of the query.
-The supported fieldTypes are point fields with docValues enabled or string fields with indexed=true or docValues=true.
-For string fields which are indexed=false and docValues=true please refer to the javadocs for `DocValuesTermsQuery`
-for it's performance characteristics so indexed=true will perform better for most use-cases.
+Supported field types are point fields with docValues enabled, or string fields with `indexed=true` or `docValues=true`.
+
+TIP: For string fields which are `indexed=false` and `docValues=true`, please refer to the javadocs for {lucene-javadocs}sandbox/org/apache/lucene/search/DocValuesTermsQuery.html[`DocValuesTermsQuery`]
+for it's performance characteristics so `indexed=true` will perform better for most use-cases.
=== Graph Query Parameters
@@ -688,24 +689,24 @@ The main query, for both of these parsers, is parsed straightforwardly from the
This parser accepts the following parameters:
`f`::
-The field to use (required).
+The field to use. This parameter is required.
`func`::
-Payload function: min, max, average, sum (required).
+The payload function. The options are: `min`, `max`, `average`, or `sum`. This parameter is required.
`operator`::
-Search operator: or , phrase ( default ) (optional). This defines if the search query should be an OR
-query or a phrase query
+A search operator. The options are `or` and `phrase`, which is the default. This defines if the search query should be an OR query or a phrase query.
`includeSpanScore`::
-If `true`, multiples computed payload factor by the score of the original query. If `false`, the default, the computed payload factor is the score.
+If `true`, multiples the computed payload factor by the score of the original query. If `false`, the default, the computed payload factor is the score.
-*Example*
+*Examples*
[source,text]
-----
{!payload_score f=my_field_dpf v=some_term func=max}
-----
+
+[source,text]
+{!payload_score f=payload_field func=sum operator=or}A B C
=== Payload Check Parser
diff --git a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
index 6271cb6..c2a33e5 100644
--- a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
@@ -44,17 +44,22 @@ In recent versions of Solr, a `/select` requestHandler is defined by default, so
The `<requestParsers>` sub-element controls values related to parsing requests. This is an empty XML element that doesn't have any content, only attributes.
-The attribute `enableRemoteStreaming` controls whether remote streaming of content is allowed. If omitted or set to `false` (the default), streaming will not be allowed. Setting it to `true` lets you specify the location of content to be streamed using `stream.file` or `stream.url` parameters.
-
-The attribute `enableStreamBody` controls whether streaming content from the HTTP parameter `stream.body` is allowed. If omitted or set to `false` (the default), streaming will not be allowed. Setting it to `true` lets you pass data in the `stream.body` parameter.
+`enableRemoteStreaming`::
+This attribute controls whether remote streaming of content is allowed. If omitted or set to `false` (the default), streaming will not be allowed. Setting it to `true` lets you specify the location of content to be streamed using `stream.file` or `stream.url` parameters.
+`enableStreamBody`::
+This attribute controls whether streaming content from the HTTP parameter `stream.body` is allowed. If omitted or set to `false` (the default), streaming will not be allowed. Setting it to `true` lets you pass data in the `stream.body` parameter.
++
If you enable remote streaming, be sure that you have authentication enabled. Otherwise, someone could potentially gain access to your content by accessing arbitrary URLs. It's also a good idea to place Solr behind a firewall to prevent it from being accessed from untrusted clients.
-The attribute `multipartUploadLimitInKB` sets an upper limit in kilobytes on the size of a document that may be submitted in a multi-part HTTP POST request. The value specified is multiplied by 1024 to determine the size in bytes. A value of `-1` means MAX_INT, which is also the system default if omitted.
+`multipartUploadLimitInKB`::
+This attribute sets an upper limit in kilobytes on the size of a document that may be submitted in a multi-part HTTP POST request. The value specified is multiplied by 1024 to determine the size in bytes. A value of `-1` means MAX_INT, which is also the system default if omitted.
-The attribute `formdataUploadLimitInKB` sets a limit in kilobytes on the size of form data (application/x-www-form-urlencoded) submitted in a HTTP POST request, which can be used to pass request parameters that will not fit in a URL. A value of `-1` means MAX_INT, which is also the system default if omitted.
+`formdataUploadLimitInKB`::
+This attribute sets a limit in kilobytes on the size of form data (`application/x-www-form-urlencoded`) submitted in a HTTP POST request, which can be used to pass request parameters that will not fit in a URL. A value of `-1` means MAX_INT, which is also the system default if omitted.
-The attribute `addHttpRequestToContext` can be used to indicate that the original `HttpServletRequest` object should be included in the context map of the `SolrQueryRequest` using the key `httpRequest`. This `HttpServletRequest` is not used by any Solr component, but may be useful when developing custom plugins.
+`addHttpRequestToContext`::
+This attribute can be used to indicate that the original `HttpServletRequest` object should be included in the context map of the `SolrQueryRequest` using the key `httpRequest`. This `HttpServletRequest` is not used by any Solr component, but may be useful when developing custom plugins.
[source,xml]
----
@@ -65,7 +70,7 @@ The attribute `addHttpRequestToContext` can be used to indicate that the origina
addHttpRequestToContext="false" />
----
-The below command is an example of how to enable RemoteStreaming and BodyStreaming through <<config-api.adoc#creating-and-updating-common-properties,Config API>>:
+The below command is an example of how to enable RemoteStreaming and BodyStreaming through the <<config-api.adoc#creating-and-updating-common-properties,Config API>>:
[source,bash]
----
diff --git a/solr/solr-ref-guide/src/solr-control-script-reference.adoc b/solr/solr-ref-guide/src/solr-control-script-reference.adoc
index 04d50f7..e42542a 100644
--- a/solr/solr-ref-guide/src/solr-control-script-reference.adoc
+++ b/solr/solr-ref-guide/src/solr-control-script-reference.adoc
@@ -115,9 +115,11 @@ Start Solr on the defined port. If this is not specified, '8983' will be used.
*Example*: `bin/solr start -p 8655`
`-s <dir>`::
-Sets the solr.solr.home system property; Solr will create core directories under this directory. This allows you to run multiple Solr instances on the same host while reusing the same server directory set using the -d parameter. If set, the specified directory should contain a solr.xml file, unless solr.xml exists in ZooKeeper. The default value is `server/solr`.
+Sets the `solr.solr.home` system property; Solr will create core directories under this directory. This allows you to run multiple Solr instances on the same host while reusing the same server directory set using the `-d` parameter.
+
-This parameter is ignored when running examples (-e), as the solr.solr.home depends on which example is run.
+If set, the specified directory should contain a `solr.xml` file, unless `solr.xml` exists in ZooKeeper. The default value is `server/solr`.
++
+This parameter is ignored when running examples (`-e`), as the `solr.solr.home` depends on which example is run.
+
*Example*: `bin/solr start -s newHome`
@@ -298,20 +300,19 @@ Solr process 39827 running on port 8865
=== Assert
-The `assert` command sanity-checks common issues with Solr installations. These include checking the ownership/existence of particular directories, and ensuring Solr is available on the expected URL. The command can either output a specified error message, or change its exit code to indicate errors.
+The `assert` command sanity checks common issues with Solr installations. These include checking the ownership/existence of particular directories, and ensuring Solr is available on the expected URL. The command can either output a specified error message, or change its exit code to indicate errors.
As an example:
-`bin/solr assert --exists /opt/bin/solr`
+[source,bash]
+bin/solr assert --exists /opt/bin/solr
Results in the output below:
[source,plain]
-----
-
ERROR: Directory /opt/bin/solr does not exist.
-----
+Use `bin/solr assert -help` for a full list of options.
=== Healthcheck
diff --git a/solr/solr-ref-guide/src/update-request-processors.adoc b/solr/solr-ref-guide/src/update-request-processors.adoc
index f40f909..085ad42 100644
--- a/solr/solr-ref-guide/src/update-request-processors.adoc
+++ b/solr/solr-ref-guide/src/update-request-processors.adoc
@@ -261,9 +261,10 @@ What follows are brief descriptions of the currently available update request pr
{solr-javadocs}/solr-core/org/apache/solr/update/processor/AddSchemaFieldsUpdateProcessorFactory.html[AddSchemaFieldsUpdateProcessorFactory]:: This processor will dynamically add fields to the schema if an input document contains one or more fields that don't match any field or dynamic field in the schema.
-{solr-javadocs}/solr-core/org/apache/solr/update/processor/AtomicUpdateRequestProcessorFactory.html[AtomicUpdateProcessorFactory]:: This processor will convert conventional field-value documents to atomic update documents.
+{solr-javadocs}/solr-core/org/apache/solr/update/processor/AtomicUpdateRequestProcessorFactory.html[AtomicUpdateProcessorFactory]:: This processor will convert conventional field-value documents to atomic update documents. This processor can be used at runtime (without defining it in `solrconfig.xml`), see the section <<atomicupdateprocessorfactory>> below.
{solr-javadocs}/solr-core/org/apache/solr/update/processor/ClassificationUpdateProcessorFactory.html[ClassificationUpdateProcessorFactory]:: This processor uses Lucene's classification module to provide simple document classification. See https://wiki.apache.org/solr/SolrClassification for more details on how to use this processor.
+
{solr-javadocs}/solr-core/org/apache/solr/update/processor/CloneFieldUpdateProcessorFactory.html[CloneFieldUpdateProcessorFactory]:: Clones the values found in any matching _source_ field into the configured _dest_ field.
{solr-javadocs}/solr-core/org/apache/solr/update/processor/DefaultValueUpdateProcessorFactory.html[DefaultValueUpdateProcessorFactory]:: A simple processor that adds a default value to any document which does not already have a value in fieldName.
@@ -282,11 +283,13 @@ What follows are brief descriptions of the currently available update request pr
{solr-javadocs}/solr-core/org/apache/solr/update/processor/StatelessScriptUpdateProcessorFactory.html[StatelessScriptUpdateProcessorFactory]:: An update request processor factory that enables the use of update processors implemented as scripts.
+{solr-javadocs}/solr-core/org/apache/solr/update/processor/TemplateUpdateProcessorFactory.html[TemplateUpdateProcessorFactory]:: Allows adding new fields to documents based on a template pattern. This update processor can also be used at runtime (without defining it in `solrconfig.xml`), see the section <<templateupdateprocessorfactory>> below.
+
{solr-javadocs}/solr-core/org/apache/solr/update/processor/TimestampUpdateProcessorFactory.html[TimestampUpdateProcessorFactory]:: An update processor that adds a newly generated date value of "NOW" to any document being added that does not already have a value in the specified field.
{solr-javadocs}/solr-core/org/apache/solr/update/processor/URLClassifyProcessorFactory.html[URLClassifyProcessorFactory]:: Update processor which examines a URL and outputs to various other fields with characteristics of that URL, including length, number of path levels, whether it is a top level URL (levels==0), whether it looks like a landing/index page, a canonical representation of the URL (e.g., stripping index.html), the domain and path parts of the URL, etc.
-{solr-javadocs}/solr-core/org/apache/solr/update/processor/UUIDUpdateProcessorFactory.html[UUIDUpdateProcessorFactory]:: An update processor that adds a newly generated UUID value to any document being added that does not already have a value in the specified field.
+{solr-javadocs}/solr-core/org/apache/solr/update/processor/UUIDUpdateProcessorFactory.html[UUIDUpdateProcessorFactory]:: An update processor that adds a newly generated UUID value to any document being added that does not already have a value in the specified field. This processor can also be used at runtime (without defining it in `solrconfig.xml`), see the section <<uuidupdateprocessorfactory>> below.
=== FieldMutatingUpdateProcessorFactory Derived Factories
@@ -363,46 +366,50 @@ These are listed for completeness, but are part of the Solr infrastructure, part
{solr-javadocs}/solr-core/org/apache/solr/update/processor/RunUpdateProcessorFactory.html[RunUpdateProcessorFactory]:: Executes the update commands using the underlying UpdateHandler. Almost all processor chains should end with an instance of `RunUpdateProcessorFactory` unless the user is explicitly executing the update commands in an alternative custom `UpdateRequestProcessorFactory`.
=== Update Processors That Can Be Used at Runtime
-These Update processors do not need any configuration is your `solrconfig.xml` . They are automatically initialized when their name is added to the `processor` parameter. Multiple processors can be used by appending multiple processor names (comma separated)
+These Update processors do not need any configuration in `solrconfig.xml`. They are automatically initialized when their name is added to the `processor` parameter sent with an update request. Multiple processors can be used by appending multiple processor names separated by commas.
-==== TemplateUpdateProcessorFactory
+==== AtomicUpdateProcessorFactory
-The `TemplateUpdateProcessorFactory` can be used to add new fields to documents based on a template pattern.
+The `AtomicUpdateProcessorFactory` is used to atomically update documents.
-Use the parameter `processor=template` to use it. The template parameter `template.field` (multivalued) define the field to add and the pattern. Templates may contain placeholders which refer to other fields in the document. You can have multiple `Template.field` parameters in a single request.
+Use the parameter `processor=atomic` to invoke it. Use it to convert your normal `update` operations to atomic update operations. This is particularly useful when you use endpoints such as `/update/csv` or `/update/json/docs` which does not otherwise have a syntax for atomic operations.
For example:
[source,bash]
----
-processor=template&template.field=fullName:Mr. {firstName} {lastName}
+processor=atomic&atomic.field1=add&atomic.field2=set&atomic.field3=inc&atomic.field4=remove&atomic.field4=remove
----
-The above example would add a new field to the document called `fullName`. The fields `firstName and` `lastName` are supplied from the document fields. If either of them is missing, that part is replaced with an empty string. If those fields are multi-valued, only the first value is used.
+The above parameters convert a normal `update` operation in the following ways:
-==== AtomicUpdateProcessorFactory
+* `field1` to an atomic `add` operation
+* `field2` to an atomic `set` operation
+* `field3` to an atomic `inc` operation
+* `field4` to an atomic `remove` operation
+
+==== TemplateUpdateProcessorFactory
+The `TemplateUpdateProcessorFactory` can be used to add new fields to documents based on a template pattern.
-Name of the processor is `atomic` . Use it to convert your normal `update` operations to atomic update operations. This is particularly useful when you use endpoints such as `/update/csv` or `/update/json/docs` which does not support syntax for atomic operations.
+Use the parameter `processor=template` to use it. The template parameter `template.field` (multivalued) defines the field to add and the pattern. Templates may contain placeholders which refer to other fields in the document. You can have multiple `Template.field` parameters in a single request.
-example:
+For example:
[source,bash]
----
-processor=atomic&atomic.field1=add&atomic.field2=set&atomic.field3=inc&atomic.field4=remove&atomic.field4=remove
+processor=template&template.field=fullName:Mr. {firstName} {lastName}
----
-The above parameters convert a normal `update` operation on
-
-* `field1` to an atomic `add` operation
-* `field2` to an atomic `set` operation
-* `field3` to an atomic `inc` operation
-* `field4` to an atomic `remove` operation
+The above example would add a new field to the document called `fullName`. The fields `firstName and` `lastName` are supplied from the document fields. If either of them is missing, that part is replaced with an empty string. If those fields are multi-valued, only the first value is used.
==== UUIDUpdateProcessorFactory
-Name of the processor is `uuid` . Use it to add a UUID to a field
-example:
+The `UUIDUpdateProcessorFactory` is used to add generated UUIDs to documents.
+
+Use the parameter `processor=uuid` to invoke it. You will also need to specify the field where the UUID will be added with the `uuid.fieldName` parameter.
+
+For example:
[source,bash]
----
diff --git a/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc b/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc
index 082ccf9..c532180 100644
--- a/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc
@@ -118,7 +118,6 @@ The maximum number of logs keep. The default is `10`.
`numVersionBuckets`::
The number of buckets used to keep track of max version values when checking for re-ordered updates; increase this value to reduce the cost of synchronizing access to version buckets during high-volume indexing, this requires `(8 bytes (long) * numVersionBuckets)` of heap space per Solr core. The default is `65536`.
-
An example, to be included under `<config><updateHandler>` in `solrconfig.xml`, employing the above advanced settings:
[source,xml]