mirror of https://github.com/apache/lucene.git
ref guide: clean up monospace syntax problems
This commit is contained in:
Steve Rowe
parent
232eff0893
commit
78fcbc0623
|
|
@ -1419,9 +1419,9 @@ Case-sensitive matching, capitalized words not stopped. Token positions skip sto
|
|||
|
||||
Like <<FilterDescriptions-StopFilter,Stop Filter>>, this filter discards, or _stops_ analysis of, tokens that are on the given stop words list.
|
||||
|
||||
Suggest Stop Filter differs from Stop Filter in that it will not remove the last token unless it is followed by a token separator. For example, a query "`find the`" would preserve the '`the`' since it was not followed by a space, punctuation etc., and mark it as a `KEYWORD` so that following filters will not change or remove it.
|
||||
Suggest Stop Filter differs from Stop Filter in that it will not remove the last token unless it is followed by a token separator. For example, a query `"find the"` would preserve the `'the'` since it was not followed by a space, punctuation etc., and mark it as a `KEYWORD` so that following filters will not change or remove it.
|
||||
|
||||
By contrast, a query like "`find the popsicle`" would remove "```the```" as a stopword, since it's followed by a space. When using one of the analyzing suggesters, you would normally use the ordinary `StopFilterFactory` in your index analyzer and then SuggestStopFilter in your query analyzer.
|
||||
By contrast, a query like "`find the popsicle`" would remove '`the`' as a stopword, since it's followed by a space. When using one of the analyzing suggesters, you would normally use the ordinary `StopFilterFactory` in your index analyzer and then SuggestStopFilter in your query analyzer.
|
||||
|
||||
*Factory class:* `solr.SuggestStopFilterFactory`
|
||||
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ If the configuration options for the built-in merge policies do not fully suit y
|
|||
</mergePolicyFactory>
|
||||
----
|
||||
|
||||
The example above shows Solr's {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] being configured to sort documents in merged segments by `"timestamp desc"`, and wrapped around a `TieredMergePolicyFactory` configured to use the values `maxMergeAtOnce=10` and `segmentsPerTier=10` via the `inner` prefix defined by `SortingMergePolicyFactory`'s `wrapped.prefix` option. For more information on using `SortingMergePolicyFactory`, see <<common-query-parameters.adoc#CommonQueryParameters-ThesegmentTerminateEarlyParameter,the segmentTerminateEarly parameter>>.
|
||||
The example above shows Solr's {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] being configured to sort documents in merged segments by `"timestamp desc"`, and wrapped around a `TieredMergePolicyFactory` configured to use the values `maxMergeAtOnce=10` and `segmentsPerTier=10` via the `inner` prefix defined by `SortingMergePolicyFactory` 's `wrapped.prefix` option. For more information on using `SortingMergePolicyFactory`, see <<common-query-parameters.adoc#CommonQueryParameters-ThesegmentTerminateEarlyParameter,the segmentTerminateEarly parameter>>.
|
||||
|
||||
[[IndexConfiginSolrConfig-mergeScheduler]]
|
||||
=== mergeScheduler
|
||||
|
|
|
|||
|
|
@ -509,7 +509,7 @@ To inspect the content of the `commonFeatureStore` feature store:
|
|||
* A model need not use all the features defined in a feature store.
|
||||
* Multiple models can use the same feature store.
|
||||
|
||||
To extract features for `currentFeatureStore`'s features:
|
||||
To extract features for `currentFeatureStore` 's features:
|
||||
|
||||
`\http://localhost:8983/solr/techproducts/query?q=test&fl=id,score,[features store=currentFeatureStore]`
|
||||
|
||||
|
|
|
|||
|
|
@ -76,9 +76,9 @@ Please review the <<schema-factory-definition-in-solrconfig.adoc#schema-factory-
|
|||
|
||||
== Default Similarity Changes
|
||||
|
||||
Solr's default behavior when a Schema does not explicitly define a global <<other-schema-elements.adoc#other-schema-elements,`<similarity/>`>> is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of `SchemaSimlarityFactory` will be used. Most notably this change means that users can take advantage of per Field Type similarity declarations, with out needing to also explicitly declare a global usage of `SchemaSimlarityFactory`.
|
||||
Solr's default behavior when a Schema does not explicitly define a global <<other-schema-elements.adoc#other-schema-elements,`<similarity/>`>> is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of `SchemaSimilarityFactory` will be used. Most notably this change means that users can take advantage of per Field Type similarity declarations, with out needing to also explicitly declare a global usage of `SchemaSimilarityFactory`.
|
||||
|
||||
Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimlarityFactory`'s implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the the `luceneMatchVersion`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Simlarity` will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` declaration to change this behavior. Please review the `SchemaSimlarityFactory` javadocs for more details
|
||||
Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimilarityFactory` 's implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the the `luceneMatchVersion`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Similarity` will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` declaration to change this behavior. Please review the `SchemaSimilarityFactory` javadocs for more details
|
||||
|
||||
== Replica & Shard Delete Command Changes
|
||||
|
||||
|
|
|
|||
|
|
@ -200,7 +200,7 @@ curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
|
|||
|
||||
Permissions can be accessed using their index in the list. Use the `/admin/authorization` API to see the existing permissions and their indices.
|
||||
|
||||
The following example updates the '`role`' attribute of permission at index '`3`':
|
||||
The following example updates the `'role'` attribute of permission at index `3`:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -210,7 +210,7 @@ curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
|
|||
}' http://localhost:8983/solr/admin/authorization
|
||||
----
|
||||
|
||||
The following example deletes permission at index '`3`':
|
||||
The following example deletes permission at index `3`:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ For standalone Solr instances, there are a few parameters you should be sure to
|
|||
|
||||
* You need to use an `HdfsDirectoryFactory` and a data dir of the form `hdfs://host:port/path`
|
||||
* You need to specify an UpdateLog location of the form `hdfs://host:port/path`
|
||||
* You should specify a lock factory type of '`hdfs`' or none.
|
||||
* You should specify a lock factory type of `'hdfs'` or none.
|
||||
|
||||
If you do not modify `solrconfig.xml`, you can instead start Solr on HDFS with the following command:
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ This example will start Solr in standalone mode, using the defined JVM propertie
|
|||
In SolrCloud mode, it's best to leave the data and update log directories as the defaults Solr comes with and simply specify the `solr.hdfs.home`. All dynamically created collections will create the appropriate directories automatically under the `solr.hdfs.home` root directory.
|
||||
|
||||
* Set `solr.hdfs.home` in the form `hdfs://host:port/path`
|
||||
* You should specify a lock factory type of '`hdfs`' or none.
|
||||
* You should specify a lock factory type of `'hdfs'` or none.
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -605,7 +605,7 @@ Use the `zk cp` command for transferring files and directories between ZooKeeper
|
|||
|===
|
||||
|Parameter |Description |Example
|
||||
|-r |Optional. Do a recursive copy. The command will fail if the <src> has children unless '-r' is specified. |`-r`
|
||||
|<src> |The file or path to copy from. If prefixed with `zk:` then the source is presumed to be ZooKeeper. If no prefix or the prefix is 'file:' this is the local drive. At least one of <src> or <dest> must be prefixed by '`zk:`' or the command will fail. a|
|
||||
|<src> |The file or path to copy from. If prefixed with `zk:` then the source is presumed to be ZooKeeper. If no prefix or the prefix is 'file:' this is the local drive. At least one of <src> or <dest> must be prefixed by `'zk:'` or the command will fail. a|
|
||||
`zk:/configs/myconfigs/solrconfig.xml`
|
||||
|
||||
`file:/Users/apache/configs/src`
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ bin/solr zk mkroot /solr -z <ZK_node>:<ZK_PORT>
|
|||
[NOTE]
|
||||
====
|
||||
|
||||
If you also want to bootstrap ZooKeeper with existing `solr_home`, you can instead use use `zkcli.sh` / `zkcli.bat`'s `bootstrap` command, which will also create the chroot path if it does not exist. See <<command-line-utilities.adoc#command-line-utilities,Command Line Utilities>> for more info.
|
||||
If you also want to bootstrap ZooKeeper with existing `solr_home`, you can instead use the `zkcli.sh` / `zkcli.bat` `bootstrap` command, which will also create the chroot path if it does not exist. See <<command-line-utilities.adoc#command-line-utilities,Command Line Utilities>> for more info.
|
||||
|
||||
====
|
||||
|
||||
|
|
|
|||
|
|
@ -179,6 +179,6 @@ Here we compute some statistics for the price field. The min, max, mean, 90th, a
|
|||
[[TheStatsComponent-TheStatsComponentandFaceting]]
|
||||
== The Stats Component and Faceting
|
||||
|
||||
Sets of `stats.field` parameters can be referenced by '`tag`' when using Pivot Faceting to compute multiple statistics at every level (i.e.: field) in the tree of pivot constraints.
|
||||
Sets of `stats.field` parameters can be referenced by `'tag'` when using Pivot Faceting to compute multiple statistics at every level (i.e.: field) in the tree of pivot constraints.
|
||||
|
||||
For more information and a detailed example, please see <<faceting.adoc#Faceting-CombiningStatsComponentWithPivots,Combining Stats Component With Pivots>>.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ If you are already using Solr 6.5, Solr 6.6 should not present any major problem
|
|||
* Several changes have been made regarding the "<<other-schema-elements.adoc#OtherSchemaElements-Similarity,`Similarity`>>" used in Solr, in order to provide better default behavior for new users. There are 3 key impacts of these changes on existing users who upgrade:
|
||||
** `DefaultSimilarityFactory` has been removed. If you currently have `DefaultSimilarityFactory` explicitly referenced in your `schema.xml`, edit your config to use the functionally identical `ClassicSimilarityFactory`. See https://issues.apache.org/jira/browse/SOLR-8239[SOLR-8239] for more details.
|
||||
** The implicit default Similarity used when no `<similarity/>` is configured in `schema.xml` has been changed to `SchemaSimilarityFactory`. Users who wish to preserve back-compatible behavior should either explicitly configure `ClassicSimilarityFactory`, or ensure that the `luceneMatchVersion` for the collection is less then 6.0. See https://issues.apache.org/jira/browse/SOLR-8270[SOLR-8270] + http://SOLR-8271[SOLR-8271] for details.
|
||||
** `SchemaSimilarityFactory` has been modified to use `BM25Similarity` as the default for `fieldTypes` that do not explicitly declare a Similarity. The legacy behavior of using `ClassicSimilarity` as the default will occur if the `luceneMatchVersion` for the collection is less then 6.0, or the '`defaultSimFromFieldType`' configuration option may be used to specify any default of your choosing. See https://issues.apache.org/jira/browse/SOLR-8261[SOLR-8261] + https://issues.apache.org/jira/browse/SOLR-8329[SOLR-8329] for more details.
|
||||
** `SchemaSimilarityFactory` has been modified to use `BM25Similarity` as the default for `fieldTypes` that do not explicitly declare a Similarity. The legacy behavior of using `ClassicSimilarity` as the default will occur if the `luceneMatchVersion` for the collection is less then 6.0, or the `'defaultSimFromFieldType'` configuration option may be used to specify any default of your choosing. See https://issues.apache.org/jira/browse/SOLR-8261[SOLR-8261] + https://issues.apache.org/jira/browse/SOLR-8329[SOLR-8329] for more details.
|
||||
* If your `solrconfig.xml` file doesn't explicitly mention the `schemaFactory` to use then Solr will choose the `ManagedIndexSchemaFactory` by default. Previously it would have chosen `ClassicIndexSchemaFactory`. This means that the Schema APIs (`/<collection>/schema`) are enabled and the schema is mutable. When Solr starts your `schema.xml` file will be renamed to `managed-schema`. If you want to retain the old behaviour then please ensure that the `solrconfig.xml` explicitly uses the `ClassicIndexSchemaFactory` or your `luceneMatchVersion` in the `solrconfig.xml` is less than 6.0. See the <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>> section for more details
|
||||
* `SolrIndexSearcher.QueryCommand` and `QueryResult` were moved to their own classes. If you reference them in your code, you should import them under o.a.s.search (or use your IDE's "Organize Imports").
|
||||
* The '<<request-parameters-api.adoc#request-parameters-api,`useParams`>>' attribute specified in request handler cannot be overridden from request params. See https://issues.apache.org/jira/browse/SOLR-8698[SOLR-8698] for more details.
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ SolrDocumentList list = response.getResults();
|
|||
[[UsingSolrJ-IndexingDocuments]]
|
||||
== Indexing Documents
|
||||
|
||||
Other operations are just as simple. To index (add) a document, all you need to do is create a `SolrInputDocument` and pass it along to the `SolrClient`'s `add()` method. This example assumes that the SolrClient object called 'solr' is already created based on the examples shown earlier.
|
||||
Other operations are just as simple. To index (add) a document, all you need to do is create a `SolrInputDocument` and pass it along to the `SolrClient` 's `add()` method. This example assumes that the SolrClient object called 'solr' is already created based on the examples shown earlier.
|
||||
|
||||
[source,java]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ The "params" resource loader allows templates to be specified in Solr request pa
|
|||
|
||||
`\http://localhost:8983/solr/gettingstarted/select?q=\*:*&wt=velocity&v.template=custom&v.template.custom=CUSTOM%3A%20%23core_name`
|
||||
|
||||
where `v.template=custom` says to render a template called "custom" and `v.template.custom`'s value is the actual custom template. This is disabled by default; it'd be a niche, unusual, use case to need this enabled.
|
||||
where `v.template=custom` says to render a template called "custom" and `v.template.custom` 's value is the actual custom template. This is disabled by default; it'd be a niche, unusual, use case to need this enabled.
|
||||
|
||||
|false
|
||||
|solr.resource.loader.enabled |The "solr" resource loader is the only template loader registered by default. Templates are served from resources visible to the SolrResourceLoader under a `velocity/` subdirectory. The VelocityResponseWriter itself has some built-in templates (in its JAR file, under velocity/) that are available automatically through this loader. These built-in templates can be overridden when the same template name is in conf/velocity/ or by using the `template.base.dir` option. |true
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ You can optionally include fractional seconds if you wish, although any precisio
|
|||
* `1972-05-20T17:33:18.77Z`
|
||||
* `1972-05-20T17:33:18.7Z`
|
||||
|
||||
There must be a leading '`-`' for dates prior to year 0000, and Solr will format dates with a leading '`+`' for years after 9999. Year 0000 is considered year 1 BC; there is no such thing as year 0 AD or BC.
|
||||
There must be a leading `'-'` for dates prior to year 0000, and Solr will format dates with a leading `'+'` for years after 9999. Year 0000 is considered year 1 BC; there is no such thing as year 0 AD or BC.
|
||||
|
||||
.Query escaping may be required
|
||||
[WARNING]
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Solr nodes, clients and tools (e.g. ZkCLI) always use a java class called {solr-
|
|||
[[ZooKeeperAccessControl-ControllingCredentials]]
|
||||
=== Controlling Credentials
|
||||
|
||||
You control which credentials provider will be used by configuring the `zkCredentialsProvider` property in `solr.xml`'s `<solrcloud>` section to the name of a class (on the classpath) implementing the {solr-javadocs}/solr-solrj/org/apache/solr/common/cloud/ZkCredentialsProvider[`ZkCredentialsProvider`] interface. `server/solr/solr.xml` in the Solr distribution defines the `zkCredentialsProvider` such that it will take on the value of the same-named `zkCredentialsProvider` system property if it is defined (e.g. by uncommenting the `SOLR_ZK_CREDS_AND_ACLS` environment variable definition in `solr.in.sh/.cmd` - see below), or if not, default to the `DefaultZkCredentialsProvider` implementation.
|
||||
You control which credentials provider will be used by configuring the `zkCredentialsProvider` property in `solr.xml` 's `<solrcloud>` section to the name of a class (on the classpath) implementing the {solr-javadocs}/solr-solrj/org/apache/solr/common/cloud/ZkCredentialsProvider[`ZkCredentialsProvider`] interface. `server/solr/solr.xml` in the Solr distribution defines the `zkCredentialsProvider` such that it will take on the value of the same-named `zkCredentialsProvider` system property if it is defined (e.g. by uncommenting the `SOLR_ZK_CREDS_AND_ACLS` environment variable definition in `solr.in.sh/.cmd` - see below), or if not, default to the `DefaultZkCredentialsProvider` implementation.
|
||||
|
||||
==== Out of the Box Credential Implementations
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ You can always make you own implementation, but Solr comes with two implementati
|
|||
[[ZooKeeperAccessControl-ControllingACLs]]
|
||||
=== Controlling ACLs
|
||||
|
||||
You control which ACLs will be added by configuring `zkACLProvider` property in `solr.xml`'s `<solrcloud>` section to the name of a class (on the classpath) implementing the {solr-javadocs}//solr-solrj/org/apache/solr/common/cloud/ZkACLProvider[`ZkACLProvider`] interface. `server/solr/solr.xml` in the Solr distribution defines the `zkACLProvider` such that it will take on the value of the same-named `zkACLProvider` system property if it is defined (e.g. by uncommenting the `SOLR_ZK_CREDS_AND_ACLS` environment variable definition in `solr.in.sh/.cmd` - see below), or if not, default to the `DefaultZkACLProvider` implementation.
|
||||
You control which ACLs will be added by configuring `zkACLProvider` property in `solr.xml` 's `<solrcloud>` section to the name of a class (on the classpath) implementing the {solr-javadocs}//solr-solrj/org/apache/solr/common/cloud/ZkACLProvider[`ZkACLProvider`] interface. `server/solr/solr.xml` in the Solr distribution defines the `zkACLProvider` such that it will take on the value of the same-named `zkACLProvider` system property if it is defined (e.g. by uncommenting the `SOLR_ZK_CREDS_AND_ACLS` environment variable definition in `solr.in.sh/.cmd` - see below), or if not, default to the `DefaultZkACLProvider` implementation.
|
||||
|
||||
[[ZooKeeperAccessControl-OutoftheBoxImplementations]]
|
||||
==== Out of the Box ACL Implementations
|
||||
|
|
|
|||
Loading…
Reference in New Issue