You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2018/09/12 20:06:26 UTC
[1/2] lucene-solr:branch_7x: Fix typo in build.xml so PDF javadoc
links get converted correctly
Repository: lucene-solr
Updated Branches:
refs/heads/branch_7x 0789a77c2 -> 9523e1ae9
Fix typo in build.xml so PDF javadoc links get converted correctly
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/1a8a6eaf
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/1a8a6eaf
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/1a8a6eaf
Branch: refs/heads/branch_7x
Commit: 1a8a6eafe0220a40935d2aa9f5d4cf0b6d2eaa4b
Parents: 0789a77
Author: Cassandra Targett <ct...@apache.org>
Authored: Wed Sep 12 15:03:43 2018 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Wed Sep 12 15:06:05 2018 -0500
----------------------------------------------------------------------
solr/solr-ref-guide/build.xml | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/1a8a6eaf/solr/solr-ref-guide/build.xml
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/build.xml b/solr/solr-ref-guide/build.xml
index 08fbc40..fb6a36a 100644
--- a/solr/solr-ref-guide/build.xml
+++ b/solr/solr-ref-guide/build.xml
@@ -101,7 +101,7 @@
<!-- for the PDF guide, we always use absolute javadoc urls -->
<property name="pdf-solr-javadocs" value="https://lucene.apache.org/solr/${solr-docs-version-path}/" />
<property name="pdf-lucene-javadocs" value="https://lucene.apache.org/core/${solr-docs-version-path}/" />
-
+
<property name="build.content.dir" location="${build.dir}/content" />
<property name="main-page" value="index" />
<property name="pdf-filename" value="apache-solr-ref-guide-${solr-guide-version}.pdf" />
@@ -192,7 +192,7 @@
<attribute name="outputDirectory"/>
<attribute name="backend"/>
<attribute name="solr-javadocs" default="${pdf-solr-javadocs}" />
- <attribute name="lucene-javadocs" default="#{pdf-lucene-javadocs}" />
+ <attribute name="lucene-javadocs" default="${pdf-lucene-javadocs}" />
<attribute name="headerFooter" default="true" />
<sequential>
<!-- NOTE: we have our own variant on the asciidoctor-ant task, so that sourceDocumentName=""
@@ -247,7 +247,7 @@
</sequential>
</macrodef>
-
+
<!-- ====== PDF Build ======= -->
<target name="build-pdf" depends="bare-bones-html-validation,-build-pdf-and-reduce-pdf"
description="Builds the PDF (after building & validating a bare-bones html version)" />
@@ -265,7 +265,7 @@
/>
<move file="${build.dir}/pdf-tmp/SolrRefGuide-all.pdf" tofile="${build.dir}/pdf-tmp/RAW-${pdf-filename}" />
</target>
-
+
<target name="-reduce-pdf-size" depends="build-init,build-tools-jar">
<java classname="ReducePDFSize"
failonerror="true"
@@ -300,16 +300,16 @@
<arg value="build"/>
</exec>
</target>
-
+
<!-- ======= HTML Bare Bones Conversion =======
Does a very raw converstion of the adoc files to HTML for the purpose of link & anchor checking
-
+
Unlike the "HTML Site Build" above, this does *NOT* require Jekyll, and can be done entirely
With ivy deps fetched automatically (just like the PDF)
-->
<target name="bare-bones-html-validation" depends="build-init,build-nav-data-files"
description="Builds (w/o Jekyll) a very simple html version of the guide and runs link/anchor validation on it">
-
+
<delete dir="${build.dir}/bare-bones-html"/>
<mkdir dir="${build.dir}/bare-bones-html"/>
<asciidoctor-convert sourceDirectory="${build.content.dir}"
@@ -341,6 +341,6 @@
<echo>SITE: ${build.dir}/html-site/${main-page}.html</echo>
</target>
-
-
+
+
</project>
[2/2] lucene-solr:branch_7x: Ref Guide: fix typos;
params -> parameters
Posted by ct...@apache.org.
Ref Guide: fix typos; params -> parameters
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/9523e1ae
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/9523e1ae
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/9523e1ae
Branch: refs/heads/branch_7x
Commit: 9523e1ae91d90ff1d09f9f07c3a78a53648a8354
Parents: 1a8a6ea
Author: Cassandra Targett <ct...@apache.org>
Authored: Wed Sep 12 15:04:28 2018 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Wed Sep 12 15:06:18 2018 -0500
----------------------------------------------------------------------
.../src/common-query-parameters.adoc | 4 ++--
.../src/initparams-in-solrconfig.adoc | 2 +-
solr/solr-ref-guide/src/other-parsers.adoc | 6 ++---
.../src/pagination-of-results.adoc | 2 +-
.../src/resource-and-plugin-loading.adoc | 24 ++++++++++----------
.../src/rule-based-replica-placement.adoc | 2 +-
solr/solr-ref-guide/src/spell-checking.adoc | 2 +-
.../transforming-and-indexing-custom-json.adoc | 2 +-
8 files changed, 22 insertions(+), 22 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/common-query-parameters.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
index 85c0a0a..26b5810 100644
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -284,9 +284,9 @@ The `echoParams` parameter controls what information about request parameters is
The `echoParams` parameter accepts the following values:
-* `explicit`: This is the default value. Only parameters included in the actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) will be added to the params section of the response header.
+* `explicit`: This is the default value. Only parameters included in the actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) will be added to the `params` section of the response header.
* `all`: Include all request parameters that contributed to the query. This will include everything defined in the request handler definition found in `solrconfig.xml` as well as parameters included with the request, plus the `_` parameter. If a parameter is included in the request handler definition AND the request, it will appear multiple times in the response header.
-* `none`: Entirely removes the "params" section of the response header. No information about the request parameters will be available in the response.
+* `none`: Entirely removes the `params` section of the response header. No information about the request parameters will be available in the response.
Here is an example of a JSON response where the echoParams parameter was not included, so the default of `explicit` is active. The request URL that created this response included three parameters - `q`, `wt`, and `indent`:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc b/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc
index 7334021..c0b7fb3 100644
--- a/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc
@@ -46,7 +46,7 @@ The syntax and semantics are similar to that of a `<requestHandler>`. The follow
A comma-separated list of paths which will use the parameters. Wildcards can be used in paths to define nested paths, as described below.
`name`::
-The name of this set of parameters. The name can be used directly in a requestHandler definition if a path is not explicitly named. If you give your `<initParams>` a name, you can refer to the params in a `<requestHandler>` that is not defined as a path.
+The name of this set of parameters. The name can be used directly in a requestHandler definition if a path is not explicitly named. If you give your `<initParams>` a name, you can refer to the parameters in a `<requestHandler>` that is not defined as a path.
+
For example, if an `<initParams>` section has the name "myParams", you can call the name when defining your request handler:
+
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/other-parsers.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/other-parsers.adoc b/solr/solr-ref-guide/src/other-parsers.adoc
index bcd28eb..f22dcdc 100644
--- a/solr/solr-ref-guide/src/other-parsers.adoc
+++ b/solr/solr-ref-guide/src/other-parsers.adoc
@@ -498,11 +498,11 @@ http://localhost:8983/solr/my_graph/query?fl=id&q={!graph+from=in_edge+to=out_ed
=== Simplified Models
-The Document & Field modeling used in the above examples enumerated all of the outgoing and income edges for each node explicitly, to help demonstrate exactly how the "from" and "to" params work, and to give you an idea of what is possible. With multiple sets of fields like these for identifying incoming and outgoing edges, it's possible to model many independent Directed Graphs that contain some or all of the documents in your collection.
+The Document & Field modeling used in the above examples enumerated all of the outgoing and income edges for each node explicitly, to help demonstrate exactly how the "from" and "to" parameters work, and to give you an idea of what is possible. With multiple sets of fields like these for identifying incoming and outgoing edges, it's possible to model many independent Directed Graphs that contain some or all of the documents in your collection.
But in many cases it can also be possible to drastically simplify the model used.
-For example, the same graph shown in the diagram above can be modelled by Solr Documents that represent each node and know only the ids of the nodes they link to, without knowing anything about the incoming links:
+For example, the same graph shown in the diagram above can be modeled by Solr Documents that represent each node and know only the ids of the nodes they link to, without knowing anything about the incoming links:
[source,bash]
----
@@ -927,7 +927,7 @@ In the examples below, the result of each query is "XXX":
{!switch case=XXX case.bar=zzz case.yak=qqq}
----
-A practical usage of this `QParserPlugin`, is in specifying `appends` fq params in the configuration of a SearchHandler, to provide a fixed set of filter options for clients using custom parameter names.
+A practical usage of this parser, is in specifying `appends` filter query (`fq`) parameters in the configuration of a SearchHandler, to provide a fixed set of filter options for clients using custom parameter names.
Using the example configuration below, clients can optionally specify the custom parameters `in_stock` and `shipping` to override the default filtering behavior, but are limited to the specific set of legal values (shipping=any|free, in_stock=yes|no|all).
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/pagination-of-results.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/pagination-of-results.adoc b/solr/solr-ref-guide/src/pagination-of-results.adoc
index f3deac7..f0b0fb6 100644
--- a/solr/solr-ref-guide/src/pagination-of-results.adoc
+++ b/solr/solr-ref-guide/src/pagination-of-results.adoc
@@ -98,7 +98,7 @@ There are a few important constraints to be aware of when using `cursorMark` par
. `cursorMark` and `start` are mutually exclusive parameters.
* Your requests must either not include a `start` parameter, or it must be specified with a value of "```0```".
. `sort` clauses must include the uniqueKey field (either `asc` or `desc`).
-* If `id` is your uniqueKey field, then sort params like `id asc` and `name asc, id desc` would both work fine, but `name asc` by itself would not
+* If `id` is your uniqueKey field, then sort parameters like `id asc` and `name asc, id desc` would both work fine, but `name asc` by itself would not
. Sorts including <<working-with-dates.adoc#working-with-dates,Date Math>> based functions that involve calculations relative to `NOW` will cause confusing results, since every document will get a new sort value on every subsequent request. This can easily result in cursors that never end, and constantly return the same documents over and over – even if the documents are never updated.
+
In this situation, choose & re-use a fixed value for the <<working-with-dates.adoc#now,`NOW` request param>> in all of your cursor requests.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc b/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc
index 60cd60f..04dc840 100644
--- a/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc
+++ b/solr/solr-ref-guide/src/resource-and-plugin-loading.adoc
@@ -16,8 +16,8 @@
// specific language governing permissions and limitations
// under the License.
-Solr components can be configured using *resources*: data stored in external files that may be referred to in a location-independent fashion. Examples include: files needed by schema components, e.g. a stopword list for <<filter-descriptions.adoc#stop-filter,Stop Filter>>; and machine-learned models for <<learning-to-rank.adoc#learning-to-rank,Learning to Rank>>.
-
+Solr components can be configured using *resources*: data stored in external files that may be referred to in a location-independent fashion. Examples include: files needed by schema components, e.g., a stopword list for <<filter-descriptions.adoc#stop-filter,Stop Filter>>; and machine-learned models for <<learning-to-rank.adoc#learning-to-rank,Learning to Rank>>.
+
Solr *plugins*, which can be configured in `solrconfig.xml`, are Java classes that are normally packaged in `.jar` files along with supporting classes and data. Solr ships with a number of built-in plugins, and can also be configured to use custom plugins. Example plugins are the <<uploading-structured-data-store-data-with-the-data-import-handler.adoc#uploading-structured-data-store-data-with-the-data-import-handler,Data Import Handler>> and custom search components.
Resources and plugins may be stored:
@@ -25,29 +25,29 @@ Resources and plugins may be stored:
* in ZooKeeper under a collection's configset node (SolrCloud only);
* on a filesystem accessible to Solr nodes; or
* in Solr's <<blob-store-api.adoc#blob-store-api,Blob Store>> (SolrCloud only).
-
-NOTE: Schema components may not be stored as plugins in the Blob Store, and cannot access resources stored in the Blob Store.
-== Resource and Plugin Loading Sequence
+NOTE: Schema components may not be stored as plugins in the Blob Store, and cannot access resources stored in the Blob Store.
+
+== Resource and Plugin Loading Sequence
Under SolrCloud, resources and plugins to be loaded are first looked up in ZooKeeper under the collection's configset znode. If the resource or plugin is not found there, Solr will fall back to loading <<Resources and Plugins on the Filesystem,from the filesystem>>.
-Note that by default, Solr will not attempt to load resources and plugins from the Blob Store. To enable this, see the section <<blob-store-api.adoc#use-a-blob-in-a-handler-or-component,Use a Blob in a Handler or Component>>. When loading from the Blob Store is enabled for a component, lookups occur only in the Blob Store, and never in ZooKeeper or on the filesystem.
+Note that by default, Solr will not attempt to load resources and plugins from the Blob Store. To enable this, see the section <<blob-store-api.adoc#use-a-blob-in-a-handler-or-component,Use a Blob in a Handler or Component>>. When loading from the Blob Store is enabled for a component, lookups occur only in the Blob Store, and never in ZooKeeper or on the filesystem.
== Resources and Plugins in ConfigSets on ZooKeeper
Resources and plugins may be uploaded to ZooKeeper as part of a configset, either via the <<configsets-api.adoc#configsets-api,Configsets API>> or <<solr-control-script-reference.adoc#upload-a-configuration-set,`bin/solr zk upload`>>.
-To upload a plugin or resource to a configset already stored on ZooKeeper, you can use <<solr-control-script-reference.adoc#copy-between-local-files-and-zookeeper-znodes,`bin/solr zk cp`>>.
+To upload a plugin or resource to a configset already stored on ZooKeeper, you can use <<solr-control-script-reference.adoc#copy-between-local-files-and-zookeeper-znodes,`bin/solr zk cp`>>.
CAUTION: By default, ZooKeeper's file size limit is 1MB. If your files are larger than this, you'll need to either <<setting-up-an-external-zookeeper-ensemble.adoc#increasing-the-file-size-limit,increase the ZooKeeper file size limit>> or store them instead <<Resources and Plugins on the Filesystem,on the filesystem>>.
-
-== Resources and Plugins on the Filesystem
+
+== Resources and Plugins on the Filesystem
Under standalone Solr, when looking up a plugin or resource to be loaded, Solr's resource loader will first look under the `<instanceDir>/conf/` directory. If the plugin or resource is not found, the configured plugin and resource file paths are searched - see the section <<Lib Directives in SolrConfig>> below.
On core load, Solr's resource loader constructs a list of paths (subdirectories and jars), first under <<solr_home-lib,`solr_home/lib`>>, and then under directories pointed to by <<Lib Directives in SolrConfig,`<lib/>` directives in SolrConfig>>.
-
+
When looking up a resource or plugin to be loaded, the paths on the list are searched in the order they were added.
NOTE: Under SolrCloud, each node hosting a collection replica will need its own copy of plugins and resources to be loaded.
@@ -58,7 +58,7 @@ WARNING: Resource files *will not be loaded* if they are located directly under
=== solr_home/lib
-Each Solr node can have a directory named `lib/` under the <<taking-solr-to-production.adoc#solr-home-directory,Solr home directory>>. In order to use this directory to host resources or plugins, it must first be manually created.
+Each Solr node can have a directory named `lib/` under the <<taking-solr-to-production.adoc#solr-home-directory,Solr home directory>>. In order to use this directory to host resources or plugins, it must first be manually created.
=== Lib Directives in SolrConfig
@@ -68,7 +68,7 @@ Loading occurs in the order `<lib/>` directives appear in `solrconfig.xml`. If t
A regular expression supplied in the `<lib/>` element's `regex` attribute value can be used to restrict which subdirectories and/or jar files are added to the Solr resource loader's list of search locations. If no regular expression is given, all direct subdirectory and jar children are included in the resource path list. All directories are resolved as relative to the Solr core's `instanceDir`.
-From an example SolrConfig:
+From an example SolrConfig:
[source,xml]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/rule-based-replica-placement.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/rule-based-replica-placement.adoc b/solr/solr-ref-guide/src/rule-based-replica-placement.adoc
index 66b1d45..5dbd170 100644
--- a/solr/solr-ref-guide/src/rule-based-replica-placement.adoc
+++ b/solr/solr-ref-guide/src/rule-based-replica-placement.adoc
@@ -167,7 +167,7 @@ host:!192.45.67.3
== Defining Rules
-Rules are specified per collection during collection creation as request parameters. It is possible to specify multiple ‘rule’ and ‘snitch’ params as in this example:
+Rules are specified per collection during collection creation as request parameters. It is possible to specify multiple ‘rule’ and ‘snitch’ parameters as in this example:
[source,text]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/spell-checking.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/spell-checking.adoc b/solr/solr-ref-guide/src/spell-checking.adoc
index 7911b84..c883ed9 100644
--- a/solr/solr-ref-guide/src/spell-checking.adoc
+++ b/solr/solr-ref-guide/src/spell-checking.adoc
@@ -233,7 +233,7 @@ This parameter specifies the maximum number of documents that should be collecte
The default value for this parameter is `0`, but when `spellcheck.collateExtendedResults` is false, the optimization is always used as if `1` had been specified.
`spellcheck.collateParam.*` Prefix::
-This parameter prefix can be used to specify any additional parameters that you wish to the Spellchecker to use when internally validating collation queries. For example, even if your regular search results allow for loose matching of one or more query terms via parameters like `q.op=OR` and `mm=20%` you can specify override params such as `spellcheck.collateParam.q.op=AND&spellcheck.collateParam.mm=100%` to require that only collations consisting of words that are all found in at least one document may be returned.
+This parameter prefix can be used to specify any additional parameters that you wish to the Spellchecker to use when internally validating collation queries. For example, even if your regular search results allow for loose matching of one or more query terms via parameters like `q.op=OR` and `mm=20%` you can specify override parameters such as `spellcheck.collateParam.q.op=AND&spellcheck.collateParam.mm=100%` to require that only collations consisting of words that are all found in at least one document may be returned.
`spellcheck.dictionary`::
This parameter causes Solr to use the dictionary named in the parameter's argument. The default setting is `default`. This parameter can be used to invoke a specific spellchecker on a per request basis.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9523e1ae/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc b/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc
index 36f64e1..7f7e58b 100644
--- a/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc
+++ b/solr/solr-ref-guide/src/transforming-and-indexing-custom-json.adoc
@@ -903,7 +903,7 @@ It is possible to send any JSON to the `/update/json/docs` endpoint and the defa
</initParams>
----
-So, if no params are passed, the entire JSON file would get indexed to the `\_src_` field and all the values in the input JSON would go to a field named `text`. If there is a value for the uniqueKey it is stored and if no value could be obtained from the input JSON, a UUID is created and used as the uniqueKey field value.
+So, if no parameters are passed, the entire JSON file would get indexed to the `\_src_` field and all the values in the input JSON would go to a field named `text`. If there is a value for the uniqueKey it is stored and if no value could be obtained from the input JSON, a UUID is created and used as the uniqueKey field value.
Alternately, use the Request Parameters feature to set these parameters, as shown earlier in the section <<Reusing Parameters in Multiple Requests>>.