This is an automated email from the ASF dual-hosted git repository. janhoy pushed a commit to tag history/branches/lucene-solr/branch_7_1 in repository https://gitbox.apache.org/repos/asf/solr.git
commit bb9cf90b4d260da88b027936ab95c29daf668a19 Author: Cassandra Targett <[email protected]> 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]
