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 2019/12/20 21:01:21 UTC
[lucene-solr] branch branch_8_4 updated: Ref Guide: various little
typos; clean up Solr CLI section on bin/solr export
This is an automated email from the ASF dual-hosted git repository.
ctargett pushed a commit to branch branch_8_4
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
The following commit(s) were added to refs/heads/branch_8_4 by this push:
new 3d50d19 Ref Guide: various little typos; clean up Solr CLI section on bin/solr export
3d50d19 is described below
commit 3d50d1902d9d8c8aaaf9e212f9fb320cb41ac4ec
Author: Cassandra Targett <ca...@lucidworks.com>
AuthorDate: Fri Dec 20 14:59:51 2019 -0600
Ref Guide: various little typos; clean up Solr CLI section on bin/solr export
---
.../src/common-query-parameters.adoc | 2 +-
.../src/field-type-definitions-and-properties.adoc | 4 +-
.../collections-core-admin/collection-admin.png | Bin 60968 -> 153727 bytes
solr/solr-ref-guide/src/json-facet-api.adoc | 6 +--
.../src/making-and-restoring-backups.adoc | 3 +-
solr/solr-ref-guide/src/other-parsers.adoc | 6 +--
.../src/requestdispatcher-in-solrconfig.adoc | 8 +++-
.../src/solr-control-script-reference.adoc | 45 +++++++++++++++------
.../src/the-dismax-query-parser.adoc | 5 +--
.../src/the-extended-dismax-query-parser.adoc | 3 +-
10 files changed, 50 insertions(+), 32 deletions(-)
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
index 3a85a06..d2915f4 100644
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -231,7 +231,7 @@ This value is only checked at the time of:
. Document collection
. Doc Values reading
-As this check is periodically performed, the actual time for which a request can be processed before it is aborted would be marginally greater than or equal to the value of `timeAllowed`. If the request consumes more time in other stages, custom components, etc., this parameter is not expected to abort the request. Regular search, JSON Facet and Analytics handler abandon requests in according to this parameter.
+As this check is periodically performed, the actual time for which a request can be processed before it is aborted would be marginally greater than or equal to the value of `timeAllowed`. If the request consumes more time in other stages, custom components, etc., this parameter is not expected to abort the request. Regular search, JSON Facet and the Analytics component abandon requests in accordance with this parameter.
== segmentTerminateEarly Parameter
diff --git a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
index c70d8b2..487cd4c 100644
--- a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
+++ b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
@@ -101,10 +101,10 @@ Use `false` for field types with query analyzers including filters that can matc
[[docvaluesformat]]
`docValuesFormat`::
-Defines a custom `DocValuesFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory` has been configured in `solrconfig.xml`.
+Defines a custom `DocValuesFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory`, has been configured in `solrconfig.xml`.
`postingsFormat`::
-Defines a custom `PostingsFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory` has been configured in `solrconfig.xml`.
+Defines a custom `PostingsFormat` to use for fields of this type. This requires that a schema-aware codec, such as the `SchemaCodecFactory`, has been configured in `solrconfig.xml`.
[NOTE]
diff --git a/solr/solr-ref-guide/src/images/collections-core-admin/collection-admin.png b/solr/solr-ref-guide/src/images/collections-core-admin/collection-admin.png
index 86c367f..2739ac2 100644
Binary files a/solr/solr-ref-guide/src/images/collections-core-admin/collection-admin.png and b/solr/solr-ref-guide/src/images/collections-core-admin/collection-admin.png differ
diff --git a/solr/solr-ref-guide/src/json-facet-api.adoc b/solr/solr-ref-guide/src/json-facet-api.adoc
index f395bf7..9c944fd 100644
--- a/solr/solr-ref-guide/src/json-facet-api.adoc
+++ b/solr/solr-ref-guide/src/json-facet-api.adoc
@@ -742,7 +742,7 @@ include::{example-source-dir}JsonRequestApiTest.java[tag=solrj-json-nested-cat-f
And the response will look something like:
-[source,java]
+[source,json]
----
"facets":{
"count":32,
@@ -760,7 +760,7 @@ And the response will look something like:
"top_manufacturer":{
"buckets":[{
"val":"boa",
- "count":1}]}},
+ "count":1}]}}]}}
----
@@ -805,8 +805,6 @@ include::{example-source-dir}JsonRequestApiTest.java[tag=solrj-json-nested-cat-f
====
--
-
-
In some situations the desired `sort` may be an aggregation function that is very costly to compute for every bucket. A `prelim_sort` option can be used to specify an approximation of the `sort`, for initially ranking the buckets to determine the top candidates (based on the `limit` and `overrequest`). Only after the top candidate buckets have been refined, will the actual `sort` be used.
[source,java]
diff --git a/solr/solr-ref-guide/src/making-and-restoring-backups.adoc b/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
index 836054a..9e4afd0 100644
--- a/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
+++ b/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
@@ -22,8 +22,9 @@ Solr provides two approaches to backing up and restoring Solr cores or collectio
[NOTE]
====
-Backups (and Snapshots) capture data that has been <<near-real-time-searching.adoc#commits-and-searching,_hard_ commited>>. Commiting changes using `softCommit=true` may result in changes that are visible in search results but not included in subsequent backups. Likewise, committing changes using `openSearcher=false` may result in changes committed to disk and included in subsequnt backups, even if they are not currently visible in search results.
+Backups (and Snapshots) capture data that has been <<near-real-time-searching.adoc#commits-and-searching,_hard_ commited>>. Commiting changes using `softCommit=true` may result in changes that are visible in search results but not included in subsequent backups.
+Likewise, committing changes using `openSearcher=false` may result in changes committed to disk and included in subsequent backups, even if they are not currently visible in search results.
====
== SolrCloud Backups
diff --git a/solr/solr-ref-guide/src/other-parsers.adoc b/solr/solr-ref-guide/src/other-parsers.adoc
index 12777a7..fed1985 100644
--- a/solr/solr-ref-guide/src/other-parsers.adoc
+++ b/solr/solr-ref-guide/src/other-parsers.adoc
@@ -204,7 +204,8 @@ A list of queries that *must* appear in matching documents. However, unlike `mus
== Boost Query Parser
-`BoostQParser` extends the `QParserPlugin` and creates a boosted query from the input value. The main value is any query to be "wrapped" and "boosted" -- only documents which match that query will match the final query produced by this parter. Parameter `b` is a <<function-queries.adoc#available-functions,function>> to be evaluted against each document that matches the original query, and the result of the function will be multiplied into into the final score for that document.
+`BoostQParser` extends the `QParserPlugin` and creates a boosted query from the input value. The main value is any query to be "wrapped" and "boosted" -- only documents which match that query will match the final query produced by this parser.
+Parameter `b` is a <<function-queries.adoc#available-functions,function>> to be evaluated against each document that matches the original query, and the result of the function will be multiplied into into the final score for that document.
=== Boost Query Parser Examples
@@ -233,9 +234,6 @@ q={!boost b=query($my_boost)}name:foo
my_boost=category:electronics
----
-
-
-
[[other-collapsing]]
== Collapsing Query Parser
diff --git a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
index 362e6dc..72f7038 100644
--- a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
@@ -27,9 +27,13 @@ Included are parameters for defining if it should handle `/select` urls (for Sol
`handleSelect` is for legacy back-compatibility; those new to Solr do not need to change anything about the way this is configured by default.
====
-The first configurable item is the `handleSelect` attribute on the `<requestDispatcher>` element itself. This attribute can be set to one of two values, either "true" or "false". It governs how Solr responds to requests such as `/select?qt=XXX`. The default value "false" will ignore requests to `/select` if a requestHandler is not explicitly registered with the name `/select`. A value of "true" will route query requests to the parser defined with the `qt` value if a requestHandler is not [...]
+The first configurable item is the `handleSelect` attribute on the `<requestDispatcher>` element itself.
+This attribute can be set to one of two values, either "true" or "false".
+It governs how Solr responds to requests such as `/select?qt=XXX`.
+The default value "false" will ignore requests to `/select` if a request handler is not explicitly registered with the name `/select`.
+A value of "true" will route query requests to the parser defined with the `qt` value if a request handler is not explicitly registered with the name `/select`.
-In recent versions of Solr, a `/select` requestHandler is defined by default, so a value of "false" will work fine. See the section <<requesthandlers-and-searchcomponents-in-solrconfig.adoc#requesthandlers-and-searchcomponents-in-solrconfig,RequestHandlers and SearchComponents in SolrConfig>> for more information.
+In recent versions of Solr, a `/select` request handler is defined by default, so a value of "false" will work fine. See the section <<requesthandlers-and-searchcomponents-in-solrconfig.adoc#requesthandlers-and-searchcomponents-in-solrconfig,RequestHandlers and SearchComponents in SolrConfig>> for more information.
[source,xml]
----
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 644f763..cb33ed0 100644
--- a/solr/solr-ref-guide/src/solr-control-script-reference.adoc
+++ b/solr/solr-ref-guide/src/solr-control-script-reference.adoc
@@ -881,28 +881,47 @@ Examples of this command:
`bin/solr zk mkroot /solr/production`
-== Exporting Data to a File
+== Exporting Documents to a File
-*Example*
+The `export` command will allow you to export documents from a collection in either JSON or Javabin format.
+All documents can be exported, or only those that match a query.
+
+`bin/solr export [options]`
+
+`bin/solr export -help`
+
+The `bin/solr export` command takes the following parameters:
+
+`format`::
+The file format of the export, `jsonl` (default) or `javabin`. Choosing `javabin` exports to a file with extension `.javabin` which is the native Solr format. This is compact and faster to import.
+
+`out`::
+The file name of the export.
-Export all documents from a collection `gettingstarted` to a file called `gettingstarted.json`
+`query`::
+A custom query. The default is `\*:*` which will export all documents.
-`bin/solr export -url http://localhost:8983/solr/gettingstarted limit -1`
+`fields`::
+A comma separated list of fields to be exported.
-*Arguments*
+`limit`::
+The number of documents to export. The default is `100`. The value `-1` will export all documents.
+
+*Example*
+
+Export all documents from a collection `gettingstarted`:
+
+[source,bash]
+bin/solr export -url http://localhost:8983/solr/gettingstarted limit -1
-* `format` : `jsonl` (default) or `javabin`. `format=javabin` exports to a file with extension `.javabin` which is the native Solr format. This is compact & faster to import.
-* `out` : export file name
-* `query` : a custom query, default is `*:*`.
-* `fields`: a comma separated list of fields to be exported.
-* `limit` : number of documents, default is 100, send `-1` to import all the documents.
+=== Importing Documents to a Collection
-=== Importing the Data to a Collection
+Once you have exported documents in a file, you can use the <<updatehandlers-in-solrconfig.adoc#updatehandlers-in-solrconfig,/update request handler>> to import them to a new Solr collection.
-*Example: importing the `jsonl` files*
+*Example: import `jsonl` files*
`curl -X POST -d @gettingstarted.json http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true`
-*Example: importing the `javabin` files*
+*Example: import `javabin` files*
`curl -X POST --header "Content-Type: application/javabin" --data-binary @gettingstarted.javabin http://localhost:8983/solr/gettingstarted/update?commit=true`
diff --git a/solr/solr-ref-guide/src/the-dismax-query-parser.adoc b/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
index 111df51..ce20bfc 100644
--- a/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
@@ -148,9 +148,9 @@ The only difference between the above examples, is that using the `bq` parameter
====
Generally speaking, using `bq` (or `bf`, below) is considered a poor way to "boost" documents by a secondary query because it has an "Additive" effect on the final score. The overall impact a particular `bq` parameter will have on a given document can vary a lot depending on the _absolute_ values of the scores from the original query as well as the `bq` query, which in turn depends on the complexity of the original query, and various scoring factors (TF, IDF, average field length, etc.)
-"Multiplicative Boosting" is generally considered to be a more predictable method of influcing document score, because it acts as a "scaling factor" -- increasing (or decreasing) the scores of each document by a _relative_ amount.
+"Multiplicative Boosting" is generally considered to be a more predictable method of influencing document score, because it acts as a "scaling factor" -- increasing (or decreasing) the scores of each document by a _relative_ amount.
-The <<other-parsers.adoc#boost-query-parser,`{!boost}` QParser>> provides a convinient wrapper for implementing multiplicitive boosting, and the <<the-extended-dismax-query-parser.adoc#extended-dismax-parameters,`{!edismax}` QParser>> offers a `boost` query parameter shortcut for using it.
+The <<other-parsers.adoc#boost-query-parser,`{!boost}` QParser>> provides a convenient wrapper for implementing multiplicative boosting, and the <<the-extended-dismax-query-parser.adoc#extended-dismax-parameters,`{!edismax}` QParser>> offers a `boost` query parameter shortcut for using it.
====
@@ -179,7 +179,6 @@ bq={!func}div(sales_rank,ms(NOW,release_date))
bq={!lucene}( {!func v='div(1,sum(1,price))'} )^1.5
----
-
== Examples of Queries Submitted to the DisMax Query Parser
All of the sample URLs in this section assume you are running Solr's "techproducts" example:
diff --git a/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc b/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
index 29cc007..030cc09 100644
--- a/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-extended-dismax-query-parser.adoc
@@ -54,7 +54,7 @@ Note that relaxing `mm` may cause undesired side effects, such as hurting the pr
`boost`::
A multivalued list of strings parsed as <<function-queries.adoc#available-functions,functions>> whose results will be multiplied into the score from the main query for all matching documents. This parameter is shorthand for wrapping the query produced by eDisMax using the <<other-parsers.adoc#boost-query-parser,`BoostQParserPlugin`>>.
-These two examples are equivilent:
+These two examples are equivalent:
[source,text]
----
q={!edismax qf=name}ipod
@@ -66,7 +66,6 @@ q={!boost b=div(1,sum(1,price)) v=$qq}
qq={!edismax qf=name}ipod
----
-
`lowercaseOperators`::
A Boolean parameter indicating if lowercase "and" and "or" should be treated the same as operators "AND" and "OR".
Defaults to `false`.