mirror of https://github.com/apache/lucene.git
SOLR-11509: Misc typo cleanup and copy edits for 7.1 Ref Guide
This commit is contained in:
Cassandra Targett
parent
7bf49580e9
commit
ae72dbd635
|
|
@ -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.NIOFSDirectoryFactory`], or {solr-javadocs}/solr-core/org/apache/solr/core/SimpleFSDirectoryFactory.html[`solr.SimpleFSDirectoryFactory`].
|
||||
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.NIOFSDirectoryFactory`], or {solr-javadocs}/solr-core/org/apache/solr/core/SimpleFSDirectoryFactory.html[`solr.SimpleFSDirectoryFactory`].
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,13 +366,33 @@ 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.
|
||||
|
||||
==== AtomicUpdateProcessorFactory
|
||||
|
||||
The `AtomicUpdateProcessorFactory` is used to atomically update documents.
|
||||
|
||||
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=atomic&atomic.field1=add&atomic.field2=set&atomic.field3=inc&atomic.field4=remove&atomic.field4=remove
|
||||
----
|
||||
|
||||
The above parameters convert a normal `update` operation in the following ways:
|
||||
|
||||
* `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.
|
||||
|
||||
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=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.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -380,29 +403,13 @@ processor=template&template.field=fullName:Mr. {firstName} {lastName}
|
|||
|
||||
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.
|
||||
|
||||
==== AtomicUpdateProcessorFactory
|
||||
|
||||
|
||||
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.
|
||||
|
||||
example:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
processor=atomic&atomic.field1=add&atomic.field2=set&atomic.field3=inc&atomic.field4=remove&atomic.field4=remove
|
||||
----
|
||||
|
||||
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
|
||||
|
||||
==== 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]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
Loading…
Reference in New Issue