diff --git a/solr/solr-ref-guide/src/a-quick-overview.adoc b/solr/solr-ref-guide/src/a-quick-overview.adoc index 89cc192dcfb..0542cb36aa0 100644 --- a/solr/solr-ref-guide/src/a-quick-overview.adoc +++ b/solr/solr-ref-guide/src/a-quick-overview.adoc @@ -27,17 +27,17 @@ In the scenario above, Solr runs alongside other server applications. For exampl Solr makes it easy to add the capability to search through the online store through the following steps: -. Define a _schema_. The schema tells Solr about the contents of documents it will be indexing. In the online store example, the schema would define fields for the product name, description, price, manufacturer, and so on. Solr's schema is powerful and flexible and allows you to tailor Solr's behavior to your application. See <> for all the details. +. Define a _schema_. The schema tells Solr about the contents of documents it will be indexing. In the online store example, the schema would define fields for the product name, description, price, manufacturer, and so on. Solr's schema is powerful and flexible and allows you to tailor Solr's behavior to your application. See <> for all the details. . Feed Solr documents for which your users will search. . Expose search functionality in your application. -Because Solr is based on open standards, it is highly extensible. Solr queries are simple HTTP request URLs and the response is a structured document: mainly JSON, but it could also be XML, CSV, or other formats. This means that a wide variety of clients will be able to use Solr, from other web applications to browser clients, rich client applications, and mobile devices. Any platform capable of HTTP can talk to Solr. See <> for details on client APIs. +Because Solr is based on open standards, it is highly extensible. Solr queries are simple HTTP request URLs and the response is a structured document: mainly JSON, but it could also be XML, CSV, or other formats. This means that a wide variety of clients will be able to use Solr, from other web applications to browser clients, rich client applications, and mobile devices. Any platform capable of HTTP can talk to Solr. See <> for details on client APIs. -Solr offers support for the simplest keyword searching through to complex queries on multiple fields and faceted search results. <> has more information about searching and queries. +Solr offers support for the simplest keyword searching through to complex queries on multiple fields and faceted search results. <> has more information about searching and queries. If Solr's capabilities are not impressive enough, its ability to handle very high-volume applications should do the trick. -A relatively common scenario is that you have so much data, or so many queries, that a single Solr server is unable to handle your entire workload. In this case, you can scale up the capabilities of your application using <> to better distribute the data, and the processing of requests, across many servers. Multiple options can be mixed and matched depending on the scalability you need. +A relatively common scenario is that you have so much data, or so many queries, that a single Solr server is unable to handle your entire workload. In this case, you can scale up the capabilities of your application using <> to better distribute the data, and the processing of requests, across many servers. Multiple options can be mixed and matched depending on the scalability you need. For example: "Sharding" is a scaling technique in which a collection is split into multiple logical pieces called "shards" in order to scale up the number of documents in a collection beyond what could physically fit on a single server. Incoming queries are distributed to every shard in the collection, which respond with merged results. Another technique available is to increase the "Replication Factor" of your collection, which allows you to add servers with additional copies of your collection to handle higher concurrent query load by spreading the requests around to multiple machines. Sharding and replication are not mutually exclusive, and together make Solr an extremely powerful and scalable platform. diff --git a/solr/solr-ref-guide/src/about-filters.adoc b/solr/solr-ref-guide/src/about-filters.adoc index a0577b94546..900707e840e 100644 --- a/solr/solr-ref-guide/src/about-filters.adoc +++ b/solr/solr-ref-guide/src/about-filters.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -Like <>, <> consume input and produce a stream of tokens. Filters also derive from `org.apache.lucene.analysis.TokenStream`. Unlike tokenizers, a filter's input is another TokenStream. The job of a filter is usually easier than that of a tokenizer since in most cases a filter looks at each token in the stream sequentially and decides whether to pass it along, replace it or discard it. +Like <>, <> consume input and produce a stream of tokens. Filters also derive from `org.apache.lucene.analysis.TokenStream`. Unlike tokenizers, a filter's input is another TokenStream. The job of a filter is usually easier than that of a tokenizer since in most cases a filter looks at each token in the stream sequentially and decides whether to pass it along, replace it or discard it. A filter may also do more complex analysis by looking ahead to consider multiple tokens at once, although this is less common. One hypothetical use for such a filter might be to normalize state names that would be tokenized as two words. For example, the single token "california" would be replaced with "CA", while the token pair "rhode" followed by "island" would become the single token "RI". @@ -60,4 +60,4 @@ The last filter in the above example is a stemmer filter that uses the Porter st Conversely, applying a stemmer to your query terms will allow queries containing non stem terms, like "hugging", to match documents with different variations of the same stem word, such as "hugged". This works because both the indexer and the query will map to the same stem ("hug"). -Word stemming is, obviously, very language specific. Solr includes several language-specific stemmers created by the http://snowball.tartarus.org/[Snowball] generator that are based on the Porter stemming algorithm. The generic Snowball Porter Stemmer Filter can be used to configure any of these language stemmers. Solr also includes a convenience wrapper for the English Snowball stemmer. There are also several purpose-built stemmers for non-English languages. These stemmers are described in <>. +Word stemming is, obviously, very language specific. Solr includes several language-specific stemmers created by the http://snowball.tartarus.org/[Snowball] generator that are based on the Porter stemming algorithm. The generic Snowball Porter Stemmer Filter can be used to configure any of these language stemmers. Solr also includes a convenience wrapper for the English Snowball stemmer. There are also several purpose-built stemmers for non-English languages. These stemmers are described in <>. diff --git a/solr/solr-ref-guide/src/about-this-guide.adoc b/solr/solr-ref-guide/src/about-this-guide.adoc index 956d361a1b1..d97be037ab6 100644 --- a/solr/solr-ref-guide/src/about-this-guide.adoc +++ b/solr/solr-ref-guide/src/about-this-guide.adoc @@ -28,7 +28,7 @@ The material as presented assumes that you are familiar with some basic search c The default port when running Solr is 8983. The samples, URLs and screenshots in this guide may show different ports, because the port number that Solr uses is configurable. -If you have not customized your installation of Solr, please make sure that you use port 8983 when following the examples, or configure your own installation to use the port numbers shown in the examples. For information about configuring port numbers, see the section <>. +If you have not customized your installation of Solr, please make sure that you use port 8983 when following the examples, or configure your own installation to use the port numbers shown in the examples. For information about configuring port numbers, see the section <>. Similarly, URL examples use `localhost` throughout; if you are accessing Solr from a location remote to the server hosting Solr, replace `localhost` with the proper domain or IP where Solr is running. @@ -58,7 +58,7 @@ In many cases, but not all, the parameters and outputs of API calls are the same Throughout this Guide, we have added examples of both styles with sections labeled "V1 API" and "V2 API". As of the 7.2 version of this Guide, these examples are not yet complete - more coverage will be added as future versions of the Guide are released. -The section <> provides more information about how to work with the new API structure, including how to disable it if you choose to do so. +The section <> provides more information about how to work with the new API structure, including how to disable it if you choose to do so. All APIs return a response header that includes the status of the request and the time to process it. Some APIs will also include the parameters used for the request. Many of the examples in this Guide omit this header information, which you can do locally by adding the parameter `omitHeader=true` to any request. diff --git a/solr/solr-ref-guide/src/about-tokenizers.adoc b/solr/solr-ref-guide/src/about-tokenizers.adoc index f94ef5ee0f0..b2d0c3b665d 100644 --- a/solr/solr-ref-guide/src/about-tokenizers.adoc +++ b/solr/solr-ref-guide/src/about-tokenizers.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -The job of a <> is to break up a stream of text into tokens, where each token is (usually) a sub-sequence of the characters in the text. An analyzer is aware of the field it is configured for, but a tokenizer is not. Tokenizers read from a character stream (a Reader) and produce a sequence of Token objects (a TokenStream). +The job of a <> is to break up a stream of text into tokens, where each token is (usually) a sub-sequence of the characters in the text. An analyzer is aware of the field it is configured for, but a tokenizer is not. Tokenizers read from a character stream (a Reader) and produce a sequence of Token objects (a TokenStream). Characters in the input stream may be discarded, such as whitespace or other delimiters. They may also be added to or replaced, such as mapping aliases or abbreviations to normalized forms. A token contains various metadata in addition to its text value, such as the location at which the token occurs in the field. Because a tokenizer may produce tokens that diverge from the input text, you should not assume that the text of the token is the same text that occurs in the field, or that its length is the same as the original text. It's also possible for more than one token to have the same position or refer to the same offset in the original text. Keep this in mind if you use token metadata for things like highlighting search results in the field text. @@ -52,7 +52,7 @@ The class named in the tokenizer element is not the actual tokenizer, but rather A `TypeTokenFilterFactory` is available that creates a `TypeTokenFilter` that filters tokens based on their TypeAttribute, which is set in `factory.getStopTypes`. -For a complete list of the available TokenFilters, see the section <>. +For a complete list of the available TokenFilters, see the section <>. == When to Use a CharFilter vs. a TokenFilter diff --git a/solr/solr-ref-guide/src/aliases.adoc b/solr/solr-ref-guide/src/aliases.adoc index 1c18b54ab46..57cdf6ebe5b 100644 --- a/solr/solr-ref-guide/src/aliases.adoc +++ b/solr/solr-ref-guide/src/aliases.adoc @@ -67,7 +67,7 @@ There are presently two types of routed alias: time routed and category routed. but share some common behavior. When processing an update for a routed alias, Solr initializes its - <> chain as usual, but + <> chain as usual, but when `DistributedUpdateProcessor` (DUP) initializes, it detects that the update targets a routed alias and injects `RoutedAliasUpdateProcessor` (RAUP) in front of itself. RAUP, in coordination with the Overseer, is the main part of a routed alias, and must immediately precede DUP. It is not @@ -83,7 +83,7 @@ WARNING: It's extremely important with all routed aliases that the route values with a different route value for the same ID produces two distinct documents with the same ID accessible via the alias. All query time behavior of the routed alias is *_undefined_* and not easily predictable once duplicate ID's exist. -CAUTION: It is a bad idea to use "data driven" mode (aka <>) with +CAUTION: It is a bad idea to use "data driven" mode (aka <>) with routed aliases, as duplicate schema mutations might happen concurrently leading to errors. diff --git a/solr/solr-ref-guide/src/analysis-screen.adoc b/solr/solr-ref-guide/src/analysis-screen.adoc index 40f03299a61..ec075c79d13 100644 --- a/solr/solr-ref-guide/src/analysis-screen.adoc +++ b/solr/solr-ref-guide/src/analysis-screen.adoc @@ -26,6 +26,6 @@ If you click the *Verbose Output* check box, you see more information, including image::images/analysis-screen/analysis_verbose.png[image,height=400] -In the example screenshot above, several transformations are applied to the input "Running is a sport." The words "is" and "a" have been removed and the word "running" has been changed to its basic form, "run". This is because we are using the field type `text_en` in this scenario, which is configured to remove stop words (small words that usually do not provide a great deal of context) and "stem" terms when possible to find more possible matches (this is particularly helpful with plural forms of words). If you click the question mark next to the *Analyze Fieldname/Field Type* pull-down menu, the <> will open, showing you the settings for the field specified. +In the example screenshot above, several transformations are applied to the input "Running is a sport." The words "is" and "a" have been removed and the word "running" has been changed to its basic form, "run". This is because we are using the field type `text_en` in this scenario, which is configured to remove stop words (small words that usually do not provide a great deal of context) and "stem" terms when possible to find more possible matches (this is particularly helpful with plural forms of words). If you click the question mark next to the *Analyze Fieldname/Field Type* pull-down menu, the <> will open, showing you the settings for the field specified. -The section <> describes in detail what each option is and how it may transform your data and the section <> has specific examples for using the Analysis screen. +The section <> describes in detail what each option is and how it may transform your data and the section <> has specific examples for using the Analysis screen. diff --git a/solr/solr-ref-guide/src/analytics-expression-sources.adoc b/solr/solr-ref-guide/src/analytics-expression-sources.adoc index 091c243ab9f..168ef847df1 100644 --- a/solr/solr-ref-guide/src/analytics-expression-sources.adoc +++ b/solr/solr-ref-guide/src/analytics-expression-sources.adoc @@ -22,10 +22,10 @@ These sources can be either Solr fields indexed with docValues, or constants. == Supported Field Types -The following <> are supported. +The following <> are supported. Fields of these types can be either multi-valued and single-valued. -All fields used in analytics expressions *must* have <> enabled. +All fields used in analytics expressions *must* have <> enabled. // Since Trie* fields are deprecated as of 7.0, we should consider removing Trie* fields from this list... @@ -77,7 +77,7 @@ There are two possible ways of specifying constant strings, as shown below. === Dates Dates can be specified in the same way as they are in Solr queries. Just use ISO-8601 format. -For more information, refer to the <> section. +For more information, refer to the <> section. * `2017-07-17T19:35:08Z` diff --git a/solr/solr-ref-guide/src/analytics-reduction-functions.adoc b/solr/solr-ref-guide/src/analytics-reduction-functions.adoc index bdb5e658966..57f72516eef 100644 --- a/solr/solr-ref-guide/src/analytics-reduction-functions.adoc +++ b/solr/solr-ref-guide/src/analytics-reduction-functions.adoc @@ -17,8 +17,8 @@ // specific language governing permissions and limitations // under the License. -Reduction functions reduce the values of <> -and/or unreduced <> +Reduction functions reduce the values of <> +and/or unreduced <> for every Solr Document to a single value. Below is a list of all reduction functions provided by the Analytics Component. diff --git a/solr/solr-ref-guide/src/analytics.adoc b/solr/solr-ref-guide/src/analytics.adoc index 573858be920..36708265865 100644 --- a/solr/solr-ref-guide/src/analytics.adoc +++ b/solr/solr-ref-guide/src/analytics.adoc @@ -161,7 +161,7 @@ The supported fields are listed in the <>. +The provided mapping functions are detailed in the <>. * Unreduced Mapping: Mapping a Field with another Field or Constant returns a value for every Solr Document. Unreduced mapping functions can take fields, constants as well as other unreduced mapping functions as input. @@ -170,7 +170,7 @@ Unreduced mapping functions can take fields, constants as well as other unreduce Reduction Functions:: Functions that reduce the values of sources and/or unreduced mapping functions for every Solr Document to a single value. -The provided reduction functions are detailed in the <>. +The provided reduction functions are detailed in the <>. ==== Component Ordering diff --git a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc index 1410bc42e48..df1edde5482 100644 --- a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc +++ b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc @@ -84,7 +84,7 @@ This example also defines `security.json` on the command line, but you can also [WARNING] ==== -Whenever you use any security plugins and store `security.json` in ZooKeeper, we highly recommend that you implement access control in your ZooKeeper nodes. Information about how to enable this is available in the section <>. +Whenever you use any security plugins and store `security.json` in ZooKeeper, we highly recommend that you implement access control in your ZooKeeper nodes. Information about how to enable this is available in the section <>. ==== Once `security.json` has been uploaded to ZooKeeper, you should use the appropriate APIs for the plugins you're using to update it. You can edit it manually, but you must take care to remove any version data so it will be properly updated across all ZooKeeper nodes. The version data is found at the end of the `security.json` file, and will appear as the letter "v" followed by a number, such as `{"v":138}`. @@ -93,7 +93,7 @@ Once `security.json` has been uploaded to ZooKeeper, you should use the appropri When running Solr in standalone mode, you need to create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`). -If you are using <>, you will need to place `security.json` on each node of the cluster. +If you are using <>, you will need to place `security.json` on each node of the cluster. You can use the authentication and authorization APIs, but if you are using the legacy scaling model, you will need to make the same API requests on each node separately. You can also edit `security.json` by hand if you prefer. @@ -159,7 +159,7 @@ include::securing-solr.adoc[tag=list-of-authorization-plugins] [#configuring-audit-logging] == Audit Logging -<> plugins help you keep an audit trail of events happening in your Solr cluster. +<> plugins help you keep an audit trail of events happening in your Solr cluster. Audit logging may e.g., ship data to an external audit service. A custom plugin can be implemented by extending the `AuditLoggerPlugin` class. @@ -169,8 +169,8 @@ Whenever an authentication plugin is enabled, authentication is also required fo When authentication is required the Admin UI will presented you with a login dialogue. The authentication plugins currently supported by the Admin UI are: -* <> -* <> +* <> +* <> If your plugin of choice is not supported, the Admin UI will still let you perform unrestricted operations, while for restricted operations you will need to interact with Solr by sending HTTP requests instead of through the graphical user interface of the Admin UI. All operations supported by Admin UI can be performed through Solr's RESTful APIs. diff --git a/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc b/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc index 524243a718c..325def69b41 100644 --- a/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc +++ b/solr/solr-ref-guide/src/aws-solrcloud-tutorial.adoc @@ -19,7 +19,7 @@ This guide is a tutorial on how to set up a multi-node SolrCloud cluster on https://aws.amazon.com/ec2[Amazon Web Services (AWS) EC2] instances for early development and design. -This tutorial is not meant for production systems. For one, it uses Solr's embedded ZooKeeper instance, and for production you should have at least 3 ZooKeeper nodes in an ensemble. There are additional steps you should take for a production installation; refer to <> for how to deploy Solr in production. +This tutorial is not meant for production systems. For one, it uses Solr's embedded ZooKeeper instance, and for production you should have at least 3 ZooKeeper nodes in an ensemble. There are additional steps you should take for a production installation; refer to <> for how to deploy Solr in production. In this guide we are going to: @@ -39,7 +39,7 @@ In this guide we are going to: To use this guide, you must have the following: * An https://aws.amazon.com[AWS] account. -* Familiarity with setting up a single-node SolrCloud on local machine. Refer to the <> if you have never used Solr before. +* Familiarity with setting up a single-node SolrCloud on local machine. Refer to the <> if you have never used Solr before. == Launch EC2 instances @@ -192,7 +192,7 @@ $ sudo vim /etc/hosts === Install ZooKeeper -These steps will help you install and configure a single instance of ZooKeeper on AWS. This is not sufficient for a production, use, however, where a ZooKeeper ensemble of at least three nodes is recommended. See the section <> for information about how to change this single-instance into an ensemble. +These steps will help you install and configure a single instance of ZooKeeper on AWS. This is not sufficient for a production, use, however, where a ZooKeeper ensemble of at least three nodes is recommended. See the section <> for information about how to change this single-instance into an ensemble. . Download a stable version of ZooKeeper. In this example we're using ZooKeeper v{ivy-zookeeper-version}. On the node you're using to host ZooKeeper (`zookeeper-node`), download the package and untar it: + @@ -265,6 +265,6 @@ $ bin/solr start -c -p 8983 -h solr-node-1 -z zookeeper-node:2181 ==== As noted earlier, a single ZooKeeper node is not sufficient for a production installation. See these additional resources for more information about deploying Solr in production, which can be used once you have the EC2 instances up and running: -* <> -* <> +* <> +* <> ==== diff --git a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc index dee2e3dd953..c6c3b374a65 100644 --- a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc +++ b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc @@ -18,7 +18,7 @@ Solr can support Basic authentication for users with the use of the BasicAuthPlugin. -An authorization plugin is also available to configure Solr with permissions to perform various activities in the system. The authorization plugin is described in the section <>. +An authorization plugin is also available to configure Solr with permissions to perform various activities in the system. The authorization plugin is described in the section <>. == Enable Basic Authentication @@ -26,7 +26,7 @@ To use Basic authentication, you must first create a `security.json` file. This For Basic authentication, the `security.json` file must have an `authentication` part which defines the class being used for authentication. Usernames and passwords (as a sha256(password+salt) hash) could be added when the file is created, or can be added later with the Basic authentication API, described below. -The `authorization` part is not related to Basic authentication, but is a separate authorization plugin designed to support fine-grained user access control. For more information, see the section <>. +The `authorization` part is not related to Basic authentication, but is a separate authorization plugin designed to support fine-grained user access control. For more information, see the section <>. An example `security.json` showing both sections is shown below to show how these plugins can work together: @@ -77,7 +77,7 @@ NOTE: If you have defined `ZK_HOST` in `solr.in.sh`/`solr.in.cmd` (see <>. +* Credentials are sent in plain text by default. It's recommended to use SSL for communication when Basic authentication is enabled, as described in the section <>. * A user who has access to write permissions to `security.json` will be able to modify all the permissions and how users have been assigned permissions. Special care should be taken to only grant access to editing security to appropriate users. * Your network should, of course, be secure. Even with Basic authentication enabled, you should not unnecessarily expose Solr to the outside world. diff --git a/solr/solr-ref-guide/src/cert-authentication-plugin.adoc b/solr/solr-ref-guide/src/cert-authentication-plugin.adoc index e8859fc83c3..292ee5c8fa7 100644 --- a/solr/solr-ref-guide/src/cert-authentication-plugin.adoc +++ b/solr/solr-ref-guide/src/cert-authentication-plugin.adoc @@ -36,7 +36,7 @@ An example `security.json` is shown below: === Certificate Validation Parts of certificate validation, including verifying the trust chain and peer hostname/ip address will be done by the web servlet container before the request ever reaches the authentication plugin. -These checks are described in the <> section. +These checks are described in the <> section. This plugin provides no additional checking beyond what has been configured via SSL properties. diff --git a/solr/solr-ref-guide/src/choosing-an-output-format.adoc b/solr/solr-ref-guide/src/choosing-an-output-format.adoc index 5ef7b1eaa82..1b9eb7426d8 100644 --- a/solr/solr-ref-guide/src/choosing-an-output-format.adoc +++ b/solr/solr-ref-guide/src/choosing-an-output-format.adoc @@ -18,6 +18,6 @@ Many programming environments are able to send HTTP requests and retrieve responses. Parsing the responses is a slightly more thorny problem. Fortunately, Solr makes it easy to choose an output format that will be easy to handle on the client side. -Specify a response format using the `wt` parameter in a query. The available response formats are documented in <>. +Specify a response format using the `wt` parameter in a query. The available response formats are documented in <>. Most client APIs hide this detail for you, so for many types of client applications, you won't ever have to specify a `wt` parameter. In JavaScript, however, the interface to Solr is a little closer to the metal, so you will need to add this parameter yourself. diff --git a/solr/solr-ref-guide/src/client-apis.adoc b/solr/solr-ref-guide/src/client-apis.adoc index 6f3b828ace3..99d1cbb85e8 100644 --- a/solr/solr-ref-guide/src/client-apis.adoc +++ b/solr/solr-ref-guide/src/client-apis.adoc @@ -19,16 +19,16 @@ This section discusses the available client APIs for Solr. It covers the following topics: -<>: A conceptual overview of Solr client APIs. +<>: A conceptual overview of Solr client APIs. -<>: Information about choosing a response format in Solr. +<>: Information about choosing a response format in Solr. -<>: Detailed information about SolrJ, an API for working with Java applications. +<>: Detailed information about SolrJ, an API for working with Java applications. -<>: Explains why a client API is not needed for JavaScript responses. +<>: Explains why a client API is not needed for JavaScript responses. -<>: Information about Python and JSON responses. +<>: Information about Python and JSON responses. -<>: Detailed information about using Solr with Ruby applications. +<>: Detailed information about using Solr with Ruby applications. -<>: How to find links to 3rd-party client libraries. +<>: How to find links to 3rd-party client libraries. diff --git a/solr/solr-ref-guide/src/cloud-screens.adoc b/solr/solr-ref-guide/src/cloud-screens.adoc index 26aa2b5b846..0563bfee3d1 100644 --- a/solr/solr-ref-guide/src/cloud-screens.adoc +++ b/solr/solr-ref-guide/src/cloud-screens.adoc @@ -16,14 +16,14 @@ // specific language governing permissions and limitations // under the License. -When running in <> mode, a "Cloud" option will appear in the Admin UI between <> and <>. +When running in <> mode, a "Cloud" option will appear in the Admin UI between <> and <>. -This screen provides status information about each collection & node in your cluster, as well as access to the low level data being stored in <>. +This screen provides status information about each collection & node in your cluster, as well as access to the low level data being stored in <>. .Only Visible When using SolrCloud [NOTE] ==== -The "Cloud" menu option is only available on Solr instances running in <>. Single node or leader/follower replication instances of Solr will not display this option. +The "Cloud" menu option is only available on Solr instances running in <>. Single node or leader/follower replication instances of Solr will not display this option. ==== Click on the "Cloud" option in the left-hand navigation, and a small sub-menu appears with options called "Nodes", "Tree", "ZK Status" and "Graph". The sub-view selected by default is "Nodes". diff --git a/solr/solr-ref-guide/src/cluster-node-management.adoc b/solr/solr-ref-guide/src/cluster-node-management.adoc index 6b6bbedc25f..491b6c1de3e 100644 --- a/solr/solr-ref-guide/src/cluster-node-management.adoc +++ b/solr/solr-ref-guide/src/cluster-node-management.adoc @@ -131,7 +131,7 @@ Add, edit or delete a cluster-wide property. `name`:: The name of the property. Supported properties names are `location`, `maxCoresPerNode`, `urlScheme`, and `defaultShardPreferences`. -If the <> has been enabled, the property `samplePercentage` is also available. +If the <> has been enabled, the property `samplePercentage` is also available. + Other properties can be set (for example, if you need them for custom plugins) but they must begin with the prefix `ext.`. Unknown properties that don't begin with `ext.` will be rejected. diff --git a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc index 48a7ea75e1c..f3846c1074c 100644 --- a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc +++ b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc @@ -18,7 +18,7 @@ The Collapsing query parser and the Expand component combine to form an approach to grouping documents for field collapsing in search results. -The Collapsing query parser groups documents (collapsing the result set) according to your parameters, while the Expand component provides access to documents in the collapsed group for use in results display or other processing by a client application. Collapse & Expand can together do what the older <> (`group=true`) does for _most_ use-cases but not all. Collapse and Expand are not supported when Result Grouping is enabled. Generally, you should prefer Collapse & Expand. +The Collapsing query parser groups documents (collapsing the result set) according to your parameters, while the Expand component provides access to documents in the collapsed group for use in results display or other processing by a client application. Collapse & Expand can together do what the older <> (`group=true`) does for _most_ use-cases but not all. Collapse and Expand are not supported when Result Grouping is enabled. Generally, you should prefer Collapse & Expand. [IMPORTANT] ==== @@ -39,7 +39,7 @@ The CollapsingQParser accepts the following local parameters: The field that is being collapsed on. The field must be a single valued String, Int or Float-type of field. `min` or `max`:: -Selects the group head document for each group based on which document has the min or max value of the specified numeric field or <>. +Selects the group head document for each group based on which document has the min or max value of the specified numeric field or <>. + At most only one of the `min`, `max`, or `sort` (see below) parameters may be specified. + @@ -134,7 +134,7 @@ fq={!collapse cost=1000 field=group_field} === Block Collapsing -When collapsing on the `\_root_` field, using `nullPolicy=expand` or `nullPolicy=ignore`, the Collapsing Query Parser can take advantage of the fact that all docs with identical field values are adjacent to eachother in the index in a single <>. This allows the collapsing logic to be much faster and more memory efficient. +When collapsing on the `\_root_` field, using `nullPolicy=expand` or `nullPolicy=ignore`, the Collapsing Query Parser can take advantage of the fact that all docs with identical field values are adjacent to eachother in the index in a single <>. This allows the collapsing logic to be much faster and more memory efficient. The default collapsing logic must keep track of all group head documents -- for all groups encountered so far -- until it has evaluated all documents, because each document it considers may become the new group head of any group. diff --git a/solr/solr-ref-guide/src/collection-management.adoc b/solr/solr-ref-guide/src/collection-management.adoc index 3713d162a1d..3cfc1d8c1bf 100644 --- a/solr/solr-ref-guide/src/collection-management.adoc +++ b/solr/solr-ref-guide/src/collection-management.adoc @@ -85,13 +85,13 @@ When such a collection is deleted, its autocreated configset will be deleted by `router.field`:: If this parameter is specified, the router will look at the value of the field in an input document to compute the hash and identify a shard instead of looking at the `uniqueKey` field. If the field specified is null in the document, the document will be rejected. + -Please note that <> or retrieval by document ID would also require the parameter `\_route_` (or `shard.keys`) to avoid a distributed search. +Please note that <> or retrieval by document ID would also require the parameter `\_route_` (or `shard.keys`) to avoid a distributed search. `perReplicaState`:: If `true` the states of individual replicas will be maintained as individual child of the `state.json`. default is `false` `property._name_=_value_`:: -Set core property _name_ to _value_. See the section <> for details on supported properties and values. +Set core property _name_ to _value_. See the section <> for details on supported properties and values. [WARNING] ==== @@ -474,7 +474,7 @@ The routing key prefix. For example, if the uniqueKey of a document is "a!123", The timeout, in seconds, until which write requests made to the source collection for the given `split.key` will be forwarded to the target shard. The default is 60 seconds. `property._name_=_value_`:: -Set core property _name_ to _value_. See the section <> for details on supported properties and values. +Set core property _name_ to _value_. See the section <> for details on supported properties and values. `async`:: Request ID to track this action which will be <>. @@ -1209,7 +1209,7 @@ Backs up Solr collections and associated configurations to a shared filesystem - `/admin/collections?action=BACKUP&name=myBackupName&collection=myCollectionName&location=/path/to/my/shared/drive` -The BACKUP command will backup Solr indexes and configurations for a specified collection. The BACKUP command <>. For configurations, it backs up the configset that was associated with the collection and metadata. +The BACKUP command will backup Solr indexes and configurations for a specified collection. The BACKUP command <>. For configurations, it backs up the configset that was associated with the collection and metadata. === BACKUP Parameters diff --git a/solr/solr-ref-guide/src/collection-specific-tools.adoc b/solr/solr-ref-guide/src/collection-specific-tools.adoc index a927ae5d222..3e09c927e4a 100644 --- a/solr/solr-ref-guide/src/collection-specific-tools.adoc +++ b/solr/solr-ref-guide/src/collection-specific-tools.adoc @@ -22,9 +22,9 @@ In the left-hand navigation bar, you will see a pull-down menu titled "Collectio .Only Visible When Using SolrCloud [NOTE] ==== -The "Collection Selector" pull-down menu is only available on Solr instances running in <>. +The "Collection Selector" pull-down menu is only available on Solr instances running in <>. -Single node or leader/follower replication instances of Solr will not display this menu, instead the Collection specific UI pages described in this section will be available in the <>. +Single node or leader/follower replication instances of Solr will not display this menu, instead the Collection specific UI pages described in this section will be available in the <>. ==== Clicking on the Collection Selector pull-down menu will show a list of the collections in your Solr cluster, with a search box that can be used to find a specific collection by name. When you select a collection from the pull-down, the main display of the page will display some basic metadata about the collection, and a secondary menu will appear in the left nav with links to additional collection specific administration screens. @@ -34,10 +34,10 @@ image::images/collection-specific-tools/collection_dashboard.png[image,width=482 The collection-specific UI screens are listed below, with a link to the section of this guide to find out more: // TODO: SOLR-10655 BEGIN: refactor this into a 'collection-screens-list.include.adoc' file for reuse -* <> - lets you analyze the data found in specific fields. -* <> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser. -* <> - shows the current core configuration files such as `solrconfig.xml`. -* <> - lets you submit a structured query about various elements of a core. -* <> - allows you to submit streaming expressions and see results and parsing explanations. -* <> - displays schema data in a browser window. +* <> - lets you analyze the data found in specific fields. +* <> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser. +* <> - shows the current core configuration files such as `solrconfig.xml`. +* <> - lets you submit a structured query about various elements of a core. +* <> - allows you to submit streaming expressions and see results and parsing explanations. +* <> - displays schema data in a browser window. // TODO: SOLR-10655 END diff --git a/solr/solr-ref-guide/src/collections-api.adoc b/solr/solr-ref-guide/src/collections-api.adoc index 4e4809b0a98..26ae222e1e1 100644 --- a/solr/solr-ref-guide/src/collections-api.adoc +++ b/solr/solr-ref-guide/src/collections-api.adoc @@ -22,15 +22,15 @@ A SolrCloud cluster includes a number of components. The Collections API is prov Because this API has a large number of commands and options, we've grouped the commands into the following sub-sections: -*<>*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. +*<>*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. -*<>*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. +*<>*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. -*<>*: Create, list or delete collection aliases; set alias properties. +*<>*: Create, list or delete collection aliases; set alias properties. -*<>*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. +*<>*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. -*<>*: Add or delete a replica; set replica properties; move a replica to a different node. +*<>*: Add or delete a replica; set replica properties; move a replica to a different node. == Asynchronous Calls diff --git a/solr/solr-ref-guide/src/collections-core-admin.adoc b/solr/solr-ref-guide/src/collections-core-admin.adoc index 2090dba560e..ffc228d31d9 100644 --- a/solr/solr-ref-guide/src/collections-core-admin.adoc +++ b/solr/solr-ref-guide/src/collections-core-admin.adoc @@ -16,13 +16,13 @@ // specific language governing permissions and limitations // under the License. -The Collections screen provides some basic functionality for managing your Collections, powered by the <>. +The Collections screen provides some basic functionality for managing your Collections, powered by the <>. [NOTE] ==== If you are running a single node Solr instance, you will not see a Collections option in the left nav menu of the Admin UI. -You will instead see a "Core Admin" screen that supports some comparable Core level information & manipulation via the <> instead. +You will instead see a "Core Admin" screen that supports some comparable Core level information & manipulation via the <> instead. ==== The main display of this page provides a list of collections that exist in your cluster. Clicking on a collection name provides some basic metadata about how the collection is defined, and its current shards & replicas, with options for adding and deleting individual replicas. diff --git a/solr/solr-ref-guide/src/command-line-utilities.adoc b/solr/solr-ref-guide/src/command-line-utilities.adoc index d85abdefcef..575a793108d 100644 --- a/solr/solr-ref-guide/src/command-line-utilities.adoc +++ b/solr/solr-ref-guide/src/command-line-utilities.adoc @@ -20,11 +20,11 @@ A ZooKeeper Command Line Interface (CLI) script is available to allow you to int While Solr's Administration UI includes pages dedicated to the state of your SolrCloud cluster, it does not allow you to download or modify related configuration files. -TIP: See the section <> for more information about using the Admin UI screens. +TIP: See the section <> for more information about using the Admin UI screens. -The ZooKeeper CLI scripts found in `server/scripts/cloud-scripts` let you upload configuration information to ZooKeeper, in the same ways shown in the examples in <>. It also provides a few other commands that let you link collection sets to collections, make ZooKeeper paths or clear them, and download configurations from ZooKeeper to the local filesystem. +The ZooKeeper CLI scripts found in `server/scripts/cloud-scripts` let you upload configuration information to ZooKeeper, in the same ways shown in the examples in <>. It also provides a few other commands that let you link collection sets to collections, make ZooKeeper paths or clear them, and download configurations from ZooKeeper to the local filesystem. -Many of the functions provided by the zkCli.sh script are also provided by the <>, which may be more familiar as the start script ZooKeeper maintenance commands are very similar to Unix commands. +Many of the functions provided by the zkCli.sh script are also provided by the <>, which may be more familiar as the start script ZooKeeper maintenance commands are very similar to Unix commands. .Solr's zkcli.sh vs ZooKeeper's zkCli.sh [IMPORTANT] diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc index d23812147be..a5be6f000cb 100644 --- a/solr/solr-ref-guide/src/common-query-parameters.adoc +++ b/solr/solr-ref-guide/src/common-query-parameters.adoc @@ -26,7 +26,7 @@ The defType parameter selects the query parser that Solr should use to process t `defType=dismax` -If no `defType` parameter is specified, then by default, the <> is used. (e.g., `defType=lucene`) +If no `defType` parameter is specified, then by default, the <> is used. (e.g., `defType=lucene`) == sort Parameter @@ -39,7 +39,7 @@ Solr can sort query responses according to: * The value of any primitive field (numerics, string, boolean, dates, etc.) which has `docValues="true"` (or `multiValued="false"` and `indexed="true"`, in which case the indexed terms will used to build DocValue like structures on the fly at runtime) * A SortableTextField which implicitly uses `docValues="true"` by default to allow sorting on the original input string regardless of the analyzers used for Searching. * A single-valued TextField that uses an analyzer (such as the KeywordTokenizer) that produces only a single term per document. TextField does not support `docValues="true"`, but a DocValue-like structure will be built on the fly at runtime. -** *NOTE:* If you want to be able to sort on a field whose contents you want to tokenize to facilitate searching, <> in the the Schema to clone the field. Then search on the field and sort on its clone. +** *NOTE:* If you want to be able to sort on a field whose contents you want to tokenize to facilitate searching, <> in the the Schema to clone the field. Then search on the field and sort on its clone. In the case of primitive fields, or SortableTextFields, that are `multiValued="true"` the representative value used for each doc when sorting depends on the sort direction: The minimum value in each document is used for ascending (`asc`) sorting, while the maximal value in each document is used for descending (`desc`) sorting. This default behavior is equivalent to explicitly sorting using the 2 argument `<>` function: `sort=field(name,min) asc` and `sort=field(name,max) desc` @@ -104,7 +104,7 @@ fq=popularity:[10 TO *]&fq=section:0 fq=+popularity:[10 TO *] +section:0 ---- -* The document sets from each filter query are cached independently. Thus, concerning the previous examples: use a single `fq` containing two mandatory clauses if those clauses appear together often, and use two separate `fq` parameters if they are relatively independent. (To learn about tuning cache sizes and making sure a filter cache actually exists, see <>.) +* The document sets from each filter query are cached independently. Thus, concerning the previous examples: use a single `fq` containing two mandatory clauses if those clauses appear together often, and use two separate `fq` parameters if they are relatively independent. (To learn about tuning cache sizes and making sure a filter cache actually exists, see <>.) * It is also possible to use <> inside the `fq` to cache clauses individually and - among other things - to achieve union of cached filter queries. * As with all parameters: special characters in an URL need to be properly escaped and encoded as hex values. Online tools are available to help you with URL-encoding. For example: http://meyerweb.com/eric/tools/dencoder/. @@ -133,7 +133,7 @@ This table shows some basic examples of how to use `fl`: === Functions with fl -<> can be computed for each document in the result and returned as a pseudo-field: +<> can be computed for each document in the result and returned as a pseudo-field: [source,text] ---- @@ -142,7 +142,7 @@ fl=id,title,product(price,popularity) === Document Transformers with fl -<> can be used to modify the information returned about each documents in the results of a query: +<> can be used to modify the information returned about each documents in the results of a query: [source,text] ---- @@ -206,7 +206,7 @@ The default value of this parameter is blank, which causes no extra "explain inf == timeAllowed Parameter -This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. When using `timeAllowed` in combination with <>, and the `partialResults` flag is present, some matching documents may have been skipped in the result set. Additionally, if the `partialResults` flag is present, `cursorMark` can match `nextCursorMark` even if there may be more results +This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. When using `timeAllowed` in combination with <>, and the `partialResults` flag is present, some matching documents may have been skipped in the result set. Additionally, if the `partialResults` flag is present, `cursorMark` can match `nextCursorMark` even if there may be more results [source,json] ---- @@ -244,7 +244,7 @@ If set to `true`, and if <>, when early segment termination happens values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. +Similar to using <>, when early segment termination happens values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. The default value of this parameter is `false`. @@ -252,11 +252,11 @@ The default value of this parameter is `false`. This parameter may be set to either `true` or `false`. -If set to `true`, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is `false`. When using parameters such as <>, and <>, which can lead to partial results, it is advisable to keep the header, so that the `partialResults` flag can be checked, and values such as `numFound`, `nextCursorMark`, <> counts, and result <> can be interpreted in the context of partial results. +If set to `true`, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is `false`. When using parameters such as <>, and <>, which can lead to partial results, it is advisable to keep the header, so that the `partialResults` flag can be checked, and values such as `numFound`, `nextCursorMark`, <> counts, and result <> can be interpreted in the context of partial results. == wt Parameter -The `wt` parameter selects the Response Writer that Solr should use to format the query's response. For detailed descriptions of Response Writers, see <>. +The `wt` parameter selects the Response Writer that Solr should use to format the query's response. For detailed descriptions of Response Writers, see <>. If you do not define the `wt` parameter in your queries, JSON will be returned as the format of the response. diff --git a/solr/solr-ref-guide/src/config-api.adoc b/solr/solr-ref-guide/src/config-api.adoc index 0235a5e2111..379b8f7e586 100644 --- a/solr/solr-ref-guide/src/config-api.adoc +++ b/solr/solr-ref-guide/src/config-api.adoc @@ -28,7 +28,7 @@ All Config API endpoints are collection-specific, meaning this API can inspect o * `_collection_/config`: retrieve the full effective config, or modify the config. Use GET to retrieve and POST for executing commands. * `_collection_/config/overlay`: retrieve the details in the `configoverlay.json` only, removing any options defined in `solrconfig.xml` directly or implicitly through defaults. -* `_collection_/config/params`: create parameter sets that can override or take the place of parameters defined in `solrconfig.xml`. See <> for more information about this endpoint. +* `_collection_/config/params`: create parameter sets that can override or take the place of parameters defined in `solrconfig.xml`. See <> for more information about this endpoint. == Retrieving the Config @@ -85,7 +85,7 @@ http://localhost:8983/api/collections/techproducts/config/requestHandler ==== -- -The output will be details of each request handler defined in `solrconfig.xml`, all <> by Solr, and all defined with this Config API stored in `configoverlay.json`. To see the configuration for implicit request handlers, add `expandParams=true` to the request. See the documentation for the implicit request handlers for examples using this command. +The output will be details of each request handler defined in `solrconfig.xml`, all <> by Solr, and all defined with this Config API stored in `configoverlay.json`. To see the configuration for implicit request handlers, add `expandParams=true` to the request. See the documentation for the implicit request handlers for examples using this command. The available top-level sections that can be added as path parameters are: `query`, `requestHandler`, `searchComponent`, `updateHandler`, `queryResponseWriter`, `initParams`, `znodeVersion`, `listener`, `directoryFactory`, `indexConfig`, and `codecFactory`. @@ -154,7 +154,7 @@ The properties that can be configured with `set-property` and `unset-property` a *Update Handler Settings* -See <> for defaults and acceptable values for these settings. +See <> for defaults and acceptable values for these settings. * `updateHandler.autoCommit.maxDocs` * `updateHandler.autoCommit.maxTime` @@ -166,7 +166,7 @@ See <> for defaults and acceptable values for these settings. +See <> for defaults and acceptable values for these settings. _Caches and Cache Sizes_ @@ -203,14 +203,14 @@ _Query Sizing and Warming_ _Query Circuit Breakers_ -See <> for more details +See <> for more details * `query.useCircuitBreakers` * `query.memoryCircuitBreakerThresholdPct` *RequestDispatcher Settings* -See <> for defaults and acceptable values for these settings. +See <> for defaults and acceptable values for these settings. * `requestDispatcher.handleSelect` * `requestDispatcher.requestParsers.enableRemoteStreaming` @@ -859,7 +859,7 @@ Every core watches the ZooKeeper directory for the configset being used with tha For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`. Every write operation performed through the API would 'touch' the directory and all watchers are notified. Every core would check if the schema file, `solrconfig.xml`, or `configoverlay.json` has been modified by comparing the `znode` versions. If any have been modified, the core is reloaded. -If `params.json` is modified, the params object is just updated without a core reload (see <> for more information about `params.json`). +If `params.json` is modified, the params object is just updated without a core reload (see <> for more information about `params.json`). === Empty Command diff --git a/solr/solr-ref-guide/src/config-sets.adoc b/solr/solr-ref-guide/src/config-sets.adoc index 8acb03add60..b3c7f1503e6 100644 --- a/solr/solr-ref-guide/src/config-sets.adoc +++ b/solr/solr-ref-guide/src/config-sets.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -Configsets are a set of configuration files used in a Solr installation: `solrconfig.xml`, the schema, and then <> like language files, `synonyms.txt`, and others. +Configsets are a set of configuration files used in a Solr installation: `solrconfig.xml`, the schema, and then <> like language files, `synonyms.txt`, and others. Such configuration, _configsets_, can be named and then referenced by collections or cores, possibly with the intent to share them to avoid duplication. @@ -48,7 +48,7 @@ The structure should look something like this: /solrconfig.xml ---- -The default base directory is `$SOLR_HOME/configsets`. This path can be configured in `solr.xml` (see <> for details). +The default base directory is `$SOLR_HOME/configsets`. This path can be configured in `solr.xml` (see <> for details). To create a new core using a configset, pass `configSet` as one of the core properties. For example, if you do this via the CoreAdmin API: @@ -90,7 +90,7 @@ This and some demonstration ones remain on the file system but Solr does not use When you create a collection in SolrCloud, you can specify a named configset -- possibly shared. If you don't, then the `_default` will be copied and given a unique name for use by this collection. -A configset can be uploaded to ZooKeeper either via the <> or more directly via <>. +A configset can be uploaded to ZooKeeper either via the <> or more directly via <>. The Configsets API has some other operations as well, and likewise, so does the CLI. To upload a file to a configset already stored on ZooKeeper, you can use <>. diff --git a/solr/solr-ref-guide/src/configsets-api.adoc b/solr/solr-ref-guide/src/configsets-api.adoc index d5fd3dc9b58..10ff447fcec 100644 --- a/solr/solr-ref-guide/src/configsets-api.adoc +++ b/solr/solr-ref-guide/src/configsets-api.adoc @@ -23,11 +23,11 @@ Configsets are a collection of configuration files such as `solrconfig.xml`, `sy This API provides a way to upload configuration files to ZooKeeper and share the same set of configuration files between two or more collections. -Once a configset has been uploaded to ZooKeeper, use the configset name when creating the collection with the <> and the collection will use your configuration files. +Once a configset has been uploaded to ZooKeeper, use the configset name when creating the collection with the <> and the collection will use your configuration files. Configsets do not have to be shared between collections if they are uploaded with this API, but this API makes it easier to do so if you wish. An alternative to uploading your configsets in advance would be to put the configuration files into a directory under `server/solr/configsets` and using the directory name as the `-d` parameter when using `bin/solr create` to create a collection. -NOTE: This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <>. +NOTE: This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <>. The API works by passing commands to the `configs` endpoint. The path to the endpoint varies depending on the API being used: the v1 API uses `solr/admin/configs`, while the v2 API uses `api/cluster/configs`. Examples of both types are provided below. diff --git a/solr/solr-ref-guide/src/configuration-apis.adoc b/solr/solr-ref-guide/src/configuration-apis.adoc index 40ab33591e0..d3a0eeb9eb1 100644 --- a/solr/solr-ref-guide/src/configuration-apis.adoc +++ b/solr/solr-ref-guide/src/configuration-apis.adoc @@ -19,6 +19,6 @@ Solr includes several APIs that can be used to modify settings in `solrconfig.xml`. -* <> -* <> -* <> +* <> +* <> +* <> diff --git a/solr/solr-ref-guide/src/configuring-logging.adoc b/solr/solr-ref-guide/src/configuring-logging.adoc index b5cebc0f8b5..8d50cb8d147 100644 --- a/solr/solr-ref-guide/src/configuring-logging.adoc +++ b/solr/solr-ref-guide/src/configuring-logging.adoc @@ -25,7 +25,7 @@ In addition to the logging options described below, there is a way to configure == Temporary Logging Settings -You can control the amount of logging output in Solr by using the Admin Web interface. Select the *LOGGING* link. Note that this page only lets you change settings in the running system and is not saved for the next run. (For more information about the Admin Web interface, see <>.) +You can control the amount of logging output in Solr by using the Admin Web interface. Select the *LOGGING* link. Note that this page only lets you change settings in the running system and is not saved for the next run. (For more information about the Admin Web interface, see <>.) .The Logging Screen image::images/logging/logging.png[image] @@ -73,7 +73,7 @@ You can temporarily choose a different logging level as you start Solr. There ar The first way is to set the `SOLR_LOG_LEVEL` environment variable before you start Solr, or place the same variable in `bin/solr.in.sh` or `bin/solr.in.cmd`. The variable must contain an uppercase string with a supported log level (see above). -The second way is to start Solr with the -v or -q options, see <> for details. Examples: +The second way is to start Solr with the -v or -q options, see <> for details. Examples: [source,bash] ---- @@ -87,7 +87,7 @@ bin/solr start -f -q Solr uses http://logging.apache.org/log4j/log4j-{ivy-log4j-version}/[Log4J version {ivy-log4j-version}] for logging which is configured using `server/resources/log4j2.xml`. Take a moment to inspect the contents of the `log4j2.xml` file so that you are familiar with its structure. By default, Solr log messages will be written to `SOLR_LOGS_DIR/solr.log`. -When you're ready to deploy Solr in production, set the variable `SOLR_LOGS_DIR` to the location where you want Solr to write log files, such as `/var/solr/logs`. You may also want to tweak `log4j2.xml`. Note that if you installed Solr as a service using the instructions provided in <>, then see `/var/solr/log4j2.xml` instead of the default `server/resources` version. +When you're ready to deploy Solr in production, set the variable `SOLR_LOGS_DIR` to the location where you want Solr to write log files, such as `/var/solr/logs`. You may also want to tweak `log4j2.xml`. Note that if you installed Solr as a service using the instructions provided in <>, then see `/var/solr/log4j2.xml` instead of the default `server/resources` version. When starting Solr in the foreground (`-f` option), all logs will be sent to the console, in addition to `solr.log`. When starting Solr in the background, it will write all `stdout` and `stderr` output to a log file in `solr--console.log`, and automatically disable the CONSOLE logger configured in `log4j2.xml`, having the same effect as if you removed the CONSOLE appender from the rootLogger manually. diff --git a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc index 4e83f0ec63d..814d3518e67 100644 --- a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc +++ b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc @@ -30,7 +30,7 @@ The `solrconfig.xml` file is the configuration file with the most parameters affecting Solr itself. -While configuring Solr, you'll work with `solrconfig.xml` often, either directly or via the <> to create "configuration overlays" (`configoverlay.json`) to override the values in `solrconfig.xml`. +While configuring Solr, you'll work with `solrconfig.xml` often, either directly or via the <> to create "configuration overlays" (`configoverlay.json`) to override the values in `solrconfig.xml`. In `solrconfig.xml`, you configure important features such as: @@ -42,22 +42,22 @@ In `solrconfig.xml`, you configure important features such as: * the Admin Web interface -* parameters related to replication and duplication (these parameters are covered in detail in <>) +* parameters related to replication and duplication (these parameters are covered in detail in <>) The `solrconfig.xml` file is located in the `conf/` directory for each collection. Several well-commented example files can be found in the `server/solr/configsets/` directories demonstrating best practices for many different types of installations. We've covered the options in the following sections: -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> Some SolrConfig aspects are covered in other sections. See <>, which can be used for both Plugins and Resources. @@ -86,11 +86,11 @@ Which means the lock type defaults to "native" but when starting Solr, you could bin/solr start -Dsolr.lock.type=none ---- -In general, any Java system property that you want to set can be passed through the `bin/solr` script using the standard `-Dproperty=value` syntax. Alternatively, you can add common system properties to the `SOLR_OPTS` environment variable defined in the Solr include file (`bin/solr.in.sh` or `bin/solr.in.cmd`). For more information about how the Solr include file works, refer to: <>. +In general, any Java system property that you want to set can be passed through the `bin/solr` script using the standard `-Dproperty=value` syntax. Alternatively, you can add common system properties to the `SOLR_OPTS` environment variable defined in the Solr include file (`bin/solr.in.sh` or `bin/solr.in.cmd`). For more information about how the Solr include file works, refer to: <>. === Config API to Override solrconfig.xml -The <> allows you to use an API to modify Solr's configuration, specifically user defined properties. Changes made with this API are stored in a file named `configoverlay.json`. This file should only be edited with the API, but will look like this example: +The <> allows you to use an API to modify Solr's configuration, specifically user defined properties. Changes made with this API are stored in a file named `configoverlay.json`. This file should only be edited with the API, but will look like this example: [source,json] ---- @@ -105,7 +105,7 @@ The <> allows you to use an API to modify "components":["terms"]}}} ---- -For more details, see the section <>. +For more details, see the section <>. === solrcore.properties @@ -128,7 +128,7 @@ solr.lock.type=none [IMPORTANT] ==== -The path and name of the `solrcore.properties` file can be overridden using the `properties` property in <>. +The path and name of the `solrcore.properties` file can be overridden using the `properties` property in <>. ==== @@ -196,7 +196,7 @@ For example, regardless of whether the name for a particular Solr core is explic ---- -All implicit properties use the `solr.core.` name prefix, and reflect the runtime value of the equivalent <>: +All implicit properties use the `solr.core.` name prefix, and reflect the runtime value of the equivalent <>: * `solr.core.name` * `solr.core.config` diff --git a/solr/solr-ref-guide/src/content-streams.adoc b/solr/solr-ref-guide/src/content-streams.adoc index fa579bfedb8..f3077878f18 100644 --- a/solr/solr-ref-guide/src/content-streams.adoc +++ b/solr/solr-ref-guide/src/content-streams.adoc @@ -50,7 +50,7 @@ In `solrconfig.xml`, you can enable it by changing the following `enableRemoteSt When `enableRemoteStreaming` is not specified in `solrconfig.xml`, the default behavior is to _not_ allow remote streaming (i.e., `enableRemoteStreaming="false"`). -Remote streaming can also be enabled through the <> as follows: +Remote streaming can also be enabled through the <> as follows: [.dynamic-tabs] -- @@ -84,4 +84,4 @@ Gzip doesn't apply to `stream.body`. == Debugging Requests -The implicit "dump" RequestHandler (see <>) simply outputs the contents of the Solr QueryRequest using the specified writer type `wt`. This is a useful tool to help understand what streams are available to the RequestHandlers. +The implicit "dump" RequestHandler (see <>) simply outputs the contents of the Solr QueryRequest using the specified writer type `wt`. This is a useful tool to help understand what streams are available to the RequestHandlers. diff --git a/solr/solr-ref-guide/src/copying-fields.adoc b/solr/solr-ref-guide/src/copying-fields.adoc index c61168f2e3c..a1e388f1446 100644 --- a/solr/solr-ref-guide/src/copying-fields.adoc +++ b/solr/solr-ref-guide/src/copying-fields.adoc @@ -25,7 +25,7 @@ The name of the field you want to copy is the _source_, and the name of the copy ---- -In this example, we want Solr to copy the `cat` field to a field named `text`. Fields are copied before <> is done, meaning you can have two fields with identical original content, but which use different analysis chains and are stored in the index differently. +In this example, we want Solr to copy the `cat` field to a field named `text`. Fields are copied before <> is done, meaning you can have two fields with identical original content, but which use different analysis chains and are stored in the index differently. In the example above, if the `text` destination field has data of its own in the input documents, the contents of the `cat` field will be added as additional values – just as if all of the values had originally been specified by the client. Remember to configure your fields as `multivalued="true"` if they will ultimately get multiple values (either from a multivalued source or from multiple `copyField` directives). diff --git a/solr/solr-ref-guide/src/core-specific-tools.adoc b/solr/solr-ref-guide/src/core-specific-tools.adoc index ab02c11b66f..bd23a11d3be 100644 --- a/solr/solr-ref-guide/src/core-specific-tools.adoc +++ b/solr/solr-ref-guide/src/core-specific-tools.adoc @@ -29,19 +29,19 @@ image::images/core-specific-tools/core_dashboard.png[image,width=515,height=250] The core-specific UI screens are listed below, with a link to the section of this guide to find out more: // TODO: SOLR-10655 BEGIN: refactor this into a 'core-screens-list.include.adoc' file for reuse -* <> - lets you ping a named core and determine whether the core is active. -* <> - shows statistics for plugins and other installed components. -* <> - shows you the current replication status for the core, and lets you enable/disable replication. -* <> - Provides a visualization of the underlying Lucene index segments. +* <> - lets you ping a named core and determine whether the core is active. +* <> - shows statistics for plugins and other installed components. +* <> - shows you the current replication status for the core, and lets you enable/disable replication. +* <> - Provides a visualization of the underlying Lucene index segments. // TODO: SOLR-10655 END If you are running a single node instance of Solr, additional UI screens normally displayed on a per-collection bases will also be listed: // TODO: SOLR-10655 BEGIN: refactor this into a 'collection-screens-list.include.adoc' file for reuse -* <> - lets you analyze the data found in specific fields. -* <> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser. -* <> - shows the current core configuration files such as `solrconfig.xml`. -* <> - lets you submit a structured query about various elements of a core. -* <> - allows you to submit streaming expressions and see results and parsing explanations. -* <> - displays schema data in a browser window. +* <> - lets you analyze the data found in specific fields. +* <> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser. +* <> - shows the current core configuration files such as `solrconfig.xml`. +* <> - lets you submit a structured query about various elements of a core. +* <> - allows you to submit streaming expressions and see results and parsing explanations. +* <> - displays schema data in a browser window. // TODO: SOLR-10655 END diff --git a/solr/solr-ref-guide/src/coreadmin-api.adoc b/solr/solr-ref-guide/src/coreadmin-api.adoc index 7d390f699a3..948d7fdfeee 100644 --- a/solr/solr-ref-guide/src/coreadmin-api.adoc +++ b/solr/solr-ref-guide/src/coreadmin-api.adoc @@ -17,11 +17,11 @@ // specific language governing permissions and limitations // under the License. -The Core Admin API is primarily used under the covers by the <> when running a <> cluster. +The Core Admin API is primarily used under the covers by the <> when running a <> cluster. SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of single-node or leader/follower Solr installations for core maintenance operations. -The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose <> that is used to manage Solr cores. Unlike other request handlers, the CoreAdminHandler is not attached to a single core. Instead, there is a single instance of the CoreAdminHandler in each Solr node that manages all the cores running in that node and is accessible at the `/solr/admin/cores` path. +The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose <> that is used to manage Solr cores. Unlike other request handlers, the CoreAdminHandler is not attached to a single core. Instead, there is a single instance of the CoreAdminHandler in each Solr node that manages all the cores running in that node and is accessible at the `/solr/admin/cores` path. CoreAdmin actions can be executed by via HTTP requests that specify an `action` request parameter, with additional action specific arguments provided as additional parameters. @@ -58,9 +58,9 @@ Note that this command is the only one of the Core Admin API commands that *does ==== Your CREATE call must be able to find a configuration, or it will not succeed. -When you are running SolrCloud and create a new core for a collection, the configuration will be inherited from the collection. Each collection is linked to a configName, which is stored in ZooKeeper. This satisfies the configuration requirement. There is something to note, though: if you're running SolrCloud, you should *NOT* use the CoreAdmin API at all. Use the <>. +When you are running SolrCloud and create a new core for a collection, the configuration will be inherited from the collection. Each collection is linked to a configName, which is stored in ZooKeeper. This satisfies the configuration requirement. There is something to note, though: if you're running SolrCloud, you should *NOT* use the CoreAdmin API at all. Use the <>. -When you are not running SolrCloud, if you have <> defined, you can use the `configSet` parameter as documented below. If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema` or `schema.xml`), and any files referenced by those configs. +When you are not running SolrCloud, if you have <> defined, you can use the `configSet` parameter as documented below. If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema` or `schema.xml`), and any files referenced by those configs. The config and schema filenames can be specified with the `config` and `schema` parameters, but these are expert options. One thing you could do to avoid creating the `conf` directory is use `config` and `schema` parameters that point at absolute paths, but this can lead to confusing configurations unless you fully understand what you are doing. ==== @@ -83,18 +83,18 @@ The directory where files for this core should be stored. Same as `instanceDir` Name of the config file (i.e., `solrconfig.xml`) relative to `instanceDir`. `schema`:: -Name of the schema file to use for the core. Please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See <> for details. +Name of the schema file to use for the core. Please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See <> for details. `dataDir`:: Name of the data directory relative to `instanceDir`. If absolute value is used, it must be inside `SOLR_HOME`, `SOLR_DATA_HOME` or one of the paths specified by system property `solr.allowPaths`. `configSet`:: -Name of the configset to use for this core. For more information, see the section <>. +Name of the configset to use for this core. For more information, see the section <>. `collection`:: The name of the collection to which this core belongs. The default is the name of the core. `collection._param_=_value_` causes a property of `_param_=_value_` to be set if a new collection is being created. Use `collection.configName=_config-name_` to point to the configuration for a new collection. + -WARNING: While it's possible to create a core for a non-existent collection, this approach is not supported and not recommended. Always create a collection using the <> before creating a core directly for it. +WARNING: While it's possible to create a core for a non-existent collection, this approach is not supported and not recommended. Always create a collection using the <> before creating a core directly for it. `shard`:: The shard id this core represents. Normally you want to be auto-assigned a shard id. 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 3861c4a354c..98cdb968fb7 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 @@ -29,7 +29,7 @@ By default, Solr stores its index data in a directory called `/data` under the c The `${solr.core.name}` substitution will cause the name of the current core to be substituted, which results in each core's data being kept in a separate subdirectory. -If you are using replication to replicate the Solr index (as described in <>), then the `` directory should correspond to the index directory used in the replication configuration. +If you are using replication to replicate the Solr index (as described in <>), then the `` directory should correspond to the index directory used in the replication configuration. NOTE: If the environment variable `SOLR_DATA_HOME` is defined, or if `solr.data.home` is configured for your DirectoryFactory, or if `solr.xml` contains an element `` then the location of data directory will be `//data`. @@ -55,5 +55,5 @@ The {solr-javadocs}/core/org/apache/solr/core/RAMDirectoryFactory.html[`solr.RAM [NOTE] ==== -If you are using Hadoop and would like to store your indexes in HDFS, you should use the {solr-javadocs}/core/org/apache/solr/core/HdfsDirectoryFactory.html[`solr.HdfsDirectoryFactory`] instead of either of the above implementations. For more details, see the section <>. +If you are using Hadoop and would like to store your indexes in HDFS, you should use the {solr-javadocs}/core/org/apache/solr/core/HdfsDirectoryFactory.html[`solr.HdfsDirectoryFactory`] instead of either of the above implementations. For more details, see the section <>. ==== diff --git a/solr/solr-ref-guide/src/de-duplication.adoc b/solr/solr-ref-guide/src/de-duplication.adoc index a7b30f3e4e1..282f4a9e0a7 100644 --- a/solr/solr-ref-guide/src/de-duplication.adoc +++ b/solr/solr-ref-guide/src/de-duplication.adoc @@ -39,7 +39,7 @@ There are two places in Solr to configure de-duplication: in `solrconfig.xml` an === In solrconfig.xml -The `SignatureUpdateProcessorFactory` has to be registered in `solrconfig.xml` as part of an <>, as in this example: +The `SignatureUpdateProcessorFactory` has to be registered in `solrconfig.xml` as part of an <>, as in this example: [source,xml] ---- diff --git a/solr/solr-ref-guide/src/defining-core-properties.adoc b/solr/solr-ref-guide/src/defining-core-properties.adoc index e96840bf37e..9e9a611aff2 100644 --- a/solr/solr-ref-guide/src/defining-core-properties.adoc +++ b/solr/solr-ref-guide/src/defining-core-properties.adoc @@ -70,11 +70,11 @@ The following properties are available: `config`:: The configuration file name for a given core. The default is `solrconfig.xml`. -`schema`:: The schema file name for a given core. The default is `schema.xml` but please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See <> for more details. +`schema`:: The schema file name for a given core. The default is `schema.xml` but please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See <> for more details. `dataDir`:: The core's data directory (where indexes are stored) as either an absolute pathname, or a path relative to the value of `instanceDir`. This is `data` by default. -`configSet`:: The name of a defined configset, if desired, to use to configure the core (see the section <> for more details). +`configSet`:: The name of a defined configset, if desired, to use to configure the core (see the section <> for more details). `properties`:: The name of the properties file for this core. The value can be an absolute pathname or a path relative to the value of `instanceDir`. diff --git a/solr/solr-ref-guide/src/defining-fields.adoc b/solr/solr-ref-guide/src/defining-fields.adoc index 5e6b8390152..3a0c8adeac3 100644 --- a/solr/solr-ref-guide/src/defining-fields.adoc +++ b/solr/solr-ref-guide/src/defining-fields.adoc @@ -42,7 +42,7 @@ A default value that will be added automatically to any document that does not h == Optional Field Type Override Properties -Fields can have many of the same properties as field types. Properties from the table below which are specified on an individual field will override any explicit value for that property specified on the the `fieldType` of the field, or any implicit default property value provided by the underlying `fieldType` implementation. The table below is reproduced from <>, which has more details: +Fields can have many of the same properties as field types. Properties from the table below which are specified on an individual field will override any explicit value for that property specified on the the `fieldType` of the field, or any implicit default property value provided by the underlying `fieldType` implementation. The table below is reproduced from <>, which has more details: // TODO: SOLR-10655 BEGIN: refactor this into a 'field-default-properties.include.adoc' file for reuse @@ -53,16 +53,16 @@ Fields can have many of the same properties as field types. Properties from the |Property |Description |Values |Implicit Default |indexed |If true, the value of the field can be used in queries to retrieve matching documents. |true or false |true |stored |If true, the actual value of the field can be retrieved by queries. |true or false |true -|docValues |If true, the value of the field will be put in a column-oriented <> structure. |true or false |false +|docValues |If true, the value of the field will be put in a column-oriented <> structure. |true or false |false |sortMissingFirst sortMissingLast |Control the placement of documents when a sort field is not present. |true or false |false |multiValued |If true, indicates that a single document might contain multiple values for this field type. |true or false |false -|uninvertible|If true, indicates that an `indexed="true" docValues="false"` field can be "un-inverted" at query time to build up large in memory data structure to serve in place of <>. *Defaults to true for historical reasons, but users are strongly encouraged to set this to `false` for stability and use `docValues="true"` as needed.*|true or false |true +|uninvertible|If true, indicates that an `indexed="true" docValues="false"` field can be "un-inverted" at query time to build up large in memory data structure to serve in place of <>. *Defaults to true for historical reasons, but users are strongly encouraged to set this to `false` for stability and use `docValues="true"` as needed.*|true or false |true |omitNorms |If true, omits the norms associated with this field (this disables length normalization for the field, and saves some memory). *Defaults to true for all primitive (non-analyzed) field types, such as int, float, data, bool, and string.* Only full-text fields or fields need norms. |true or false |* |omitTermFreqAndPositions |If true, omits term frequency, positions, and payloads from postings for this field. This can be a performance boost for fields that don't require that information. It also reduces the storage space required for the index. Queries that rely on position that are issued on a field with this option will silently fail to find documents. *This property defaults to true for all field types that are not text fields.* |true or false |* |omitPositions |Similar to `omitTermFreqAndPositions` but preserves term frequency information. |true or false |* |termVectors termPositions termOffsets termPayloads |These options instruct Solr to maintain full term vectors for each document, optionally including position, offset and payload information for each term occurrence in those vectors. These can be used to accelerate highlighting and other ancillary functionality, but impose a substantial cost in terms of index size. They are not necessary for typical uses of Solr. |true or false |false |required |Instructs Solr to reject any attempts to add a document which does not have a value for this field. This property defaults to false. |true or false |false -|useDocValuesAsStored |If the field has `<>` enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <>. |true or false |true +|useDocValuesAsStored |If the field has `<>` enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <>. |true or false |true |large |Large fields are always lazy loaded and will only take up space in the document cache if the actual value is < 512KB. This option requires `stored="true"` and `multiValued="false"`. It's intended for fields that might have very large values so that they don't get cached in memory. |true or false |false |=== diff --git a/solr/solr-ref-guide/src/deployment-and-operations.adoc b/solr/solr-ref-guide/src/deployment-and-operations.adoc index c92352767c8..ffb11fed53f 100644 --- a/solr/solr-ref-guide/src/deployment-and-operations.adoc +++ b/solr/solr-ref-guide/src/deployment-and-operations.adoc @@ -21,18 +21,18 @@ An important aspect of Solr is that all operations and deployment can be done on Common administrative tasks include: -<>: This section provides information about all of the options available to the `bin/solr` / `bin\solr.cmd` scripts, which can start and stop Solr, configure authentication, and create or remove collections and cores. +<>: This section provides information about all of the options available to the `bin/solr` / `bin\solr.cmd` scripts, which can start and stop Solr, configure authentication, and create or remove collections and cores. -<>: Overview of the installation layout and major configuration files. +<>: Overview of the installation layout and major configuration files. -<>: Detailed steps to help you install Solr as a service and take your application to production. +<>: Detailed steps to help you install Solr as a service and take your application to production. -<>: Describes backup strategies for your Solr indexes. +<>: Describes backup strategies for your Solr indexes. -<>: How to use HDFS to store your Solr indexes and transaction logs. +<>: How to use HDFS to store your Solr indexes and transaction logs. -<>: A tutorial on deploying Solr in Amazon Web Services (AWS) using EC2 instances. +<>: A tutorial on deploying Solr in Amazon Web Services (AWS) using EC2 instances. -<>: Information for upgrading a production SolrCloud cluster. +<>: Information for upgrading a production SolrCloud cluster. -<>: Information about changes made in Solr releases. +<>: Information about changes made in Solr releases. diff --git a/solr/solr-ref-guide/src/detecting-languages-during-indexing.adoc b/solr/solr-ref-guide/src/detecting-languages-during-indexing.adoc index 92e5986dead..7924c1c8cee 100644 --- a/solr/solr-ref-guide/src/detecting-languages-during-indexing.adoc +++ b/solr/solr-ref-guide/src/detecting-languages-during-indexing.adoc @@ -28,7 +28,7 @@ You can see a comparison between the Tika and LangDetect implementations here: h For specific information on each of these language identification implementations, including a list of supported languages for each, see the relevant project websites. -For more information about language analysis in Solr, see <>. +For more information about language analysis in Solr, see <>. == Configuring Language Detection @@ -80,7 +80,7 @@ Here is an example of a minimal OpenNLP `langid` configuration in `solrconfig.xm ==== OpenNLP-specific Parameters `langid.model`:: -An OpenNLP language detection model. The OpenNLP project provides a pre-trained 103 language model on the http://opennlp.apache.org/models.html[OpenNLP site's model dowload page]. Model training instructions are provided on the http://opennlp.apache.org/docs/{ivy-opennlp-version}/manual/opennlp.html#tools.langdetect[OpenNLP website]. This parameter is required. See <> for information on where to put the model. +An OpenNLP language detection model. The OpenNLP project provides a pre-trained 103 language model on the http://opennlp.apache.org/models.html[OpenNLP site's model dowload page]. Model training instructions are provided on the http://opennlp.apache.org/docs/{ivy-opennlp-version}/manual/opennlp.html#tools.langdetect[OpenNLP website]. This parameter is required. See <> for information on where to put the model. ==== OpenNLP Language Codes diff --git a/solr/solr-ref-guide/src/distributed-search-with-index-sharding.adoc b/solr/solr-ref-guide/src/distributed-search-with-index-sharding.adoc index d51c142f70c..5efdd82b42d 100644 --- a/solr/solr-ref-guide/src/distributed-search-with-index-sharding.adoc +++ b/solr/solr-ref-guide/src/distributed-search-with-index-sharding.adoc @@ -18,7 +18,7 @@ When using traditional index sharding, you will need to consider how to query your documents. -It is highly recommended that you use <> when needing to scale up or scale out. The setup described below is legacy and was used prior to the existence of SolrCloud. SolrCloud provides for a truly distributed set of features with support for things like automatic routing, leader election, optimistic concurrency and other sanity checks that are expected out of a distributed system. +It is highly recommended that you use <> when needing to scale up or scale out. The setup described below is legacy and was used prior to the existence of SolrCloud. SolrCloud provides for a truly distributed set of features with support for things like automatic routing, leader election, optimistic concurrency and other sanity checks that are expected out of a distributed system. Everything on this page is specific to legacy setup of distributed search. Users trying out SolrCloud should not follow any of the steps or information below. @@ -79,7 +79,7 @@ Formerly a limitation was that TF/IDF relevancy computations only used shard-loc == Avoiding Distributed Deadlock with Distributed Search -Like in SolrCloud mode, inter-shard requests could lead to a distributed deadlock. It can be avoided by following the instructions in the section <>. +Like in SolrCloud mode, inter-shard requests could lead to a distributed deadlock. It can be avoided by following the instructions in the section <>. == Testing Index Sharding on Two Local Servers diff --git a/solr/solr-ref-guide/src/documents-fields-and-schema-design.adoc b/solr/solr-ref-guide/src/documents-fields-and-schema-design.adoc index ee6fd2cd070..125a0246666 100644 --- a/solr/solr-ref-guide/src/documents-fields-and-schema-design.adoc +++ b/solr/solr-ref-guide/src/documents-fields-and-schema-design.adoc @@ -21,24 +21,24 @@ This section discusses how Solr organizes its data into documents and fields, as This section includes the following topics: -<>: An introduction to the concepts covered in this section. +<>: An introduction to the concepts covered in this section. -<>: Detailed information about field types in Solr, including the field types in the default Solr schema. +<>: Detailed information about field types in Solr, including the field types in the default Solr schema. -<>: Describes how to define fields in Solr. +<>: Describes how to define fields in Solr. -<>: Describes how to populate fields with data copied from another field. +<>: Describes how to populate fields with data copied from another field. -<>: Information about using dynamic fields in order to catch and index fields that do not exactly conform to other field definitions in your schema. +<>: Information about using dynamic fields in order to catch and index fields that do not exactly conform to other field definitions in your schema. -<>: Use curl commands to read various parts of a schema or create new fields and copyField rules. +<>: Use curl commands to read various parts of a schema or create new fields and copyField rules. -<>: Describes other important elements in the Solr schema. +<>: Describes other important elements in the Solr schema. -<>: A higher-level view of the Solr schema and how its elements work together. +<>: A higher-level view of the Solr schema and how its elements work together. -<>: Describes how to create a docValues index for faster lookups. +<>: Describes how to create a docValues index for faster lookups. -<>: Automatically add previously unknown schema fields using value-based field type guessing. +<>: Automatically add previously unknown schema fields using value-based field type guessing. -<>: The request handler which provides access to information about fields in the index. This request handler powers the <> page of Solr's Admin UI. +<>: The request handler which provides access to information about fields in the index. This request handler powers the <> page of Solr's Admin UI. diff --git a/solr/solr-ref-guide/src/documents-screen.adoc b/solr/solr-ref-guide/src/documents-screen.adoc index a067526a554..d6f5d409ef5 100644 --- a/solr/solr-ref-guide/src/documents-screen.adoc +++ b/solr/solr-ref-guide/src/documents-screen.adoc @@ -31,14 +31,14 @@ The screen allows you to: ==== There are other ways to load data, see also these sections: -* <> -* <> +* <> +* <> ==== == Common Fields * Request-Handler: The first step is to define the RequestHandler. By default `/update` will be defined. Change the request handler to `/update/extract` to use Solr Cell. * Document Type: Select the Document Type to define the format of document to load. The remaining parameters may change depending on the document type selected. -* Document(s): Enter a properly-formatted Solr document corresponding to the `Document Type` selected. XML and JSON documents must be formatted in a Solr-specific format, a small illustrative document will be shown. CSV files should have headers corresponding to fields defined in the schema. More details can be found at: <>. +* Document(s): Enter a properly-formatted Solr document corresponding to the `Document Type` selected. XML and JSON documents must be formatted in a Solr-specific format, a small illustrative document will be shown. CSV files should have headers corresponding to fields defined in the schema. More details can be found at: <>. * Commit Within: Specify the number of milliseconds between the time the document is submitted and when it is available for searching. * Overwrite: If `true` the new document will replace an existing document with the same value in the `id` field. If `false` multiple documents with the same id can be added. @@ -62,7 +62,7 @@ The Document Builder provides a wizard-like interface to enter fields of a docum The File Upload option allows choosing a prepared file and uploading it. If using `/update` for the Request-Handler option, you will be limited to XML, CSV, and JSON. Other document types (e.g., Word, PDF, etc.) can be indexed using the ExtractingRequestHandler (aka, Solr Cell). You must modify the RequestHandler to `/update/extract`, which must be defined in your `solrconfig.xml` file with your desired defaults. You should also add `&literal.id` shown in the "Extracting Request Handler Params" field so the file chosen is given a unique id. -More information can be found at: <> +More information can be found at: <> == Solr Command diff --git a/solr/solr-ref-guide/src/docvalues.adoc b/solr/solr-ref-guide/src/docvalues.adoc index c481cf70029..6aa5c3b035a 100644 --- a/solr/solr-ref-guide/src/docvalues.adoc +++ b/solr/solr-ref-guide/src/docvalues.adoc @@ -30,7 +30,7 @@ In Lucene 4.0, a new approach was introduced. DocValue fields are now column-ori To use docValues, you only need to enable it for a field that you will use it with. As with all schema design, you need to define a field type and then define fields of that type with docValues enabled. All of these actions are done in `schema.xml`. -Enabling a field for docValues only requires adding `docValues="true"` to the field (or field type) definition, as in this example from the `schema.xml` of Solr's `sample_techproducts_configs` <>: +Enabling a field for docValues only requires adding `docValues="true"` to the field (or field type) definition, as in this example from the `schema.xml` of Solr's `sample_techproducts_configs` <>: [source,xml] ---- @@ -73,17 +73,17 @@ Lucene index back-compatibility is only supported for the default codec. If you === Sorting, Faceting & Functions -If `docValues="true"` for a field, then DocValues will automatically be used any time the field is used for <>, <> or <>. +If `docValues="true"` for a field, then DocValues will automatically be used any time the field is used for <>, <> or <>. === Retrieving DocValues During Search -Field values retrieved during search queries are typically returned from stored values. However, non-stored docValues fields will be also returned along with other stored fields when all fields (or pattern matching globs) are specified to be returned (e.g., "`fl=*`") for search queries depending on the effective value of the `useDocValuesAsStored` parameter for each field. For schema versions >= 1.6, the implicit default is `useDocValuesAsStored="true"`. See <> & <> for more details. +Field values retrieved during search queries are typically returned from stored values. However, non-stored docValues fields will be also returned along with other stored fields when all fields (or pattern matching globs) are specified to be returned (e.g., "`fl=*`") for search queries depending on the effective value of the `useDocValuesAsStored` parameter for each field. For schema versions >= 1.6, the implicit default is `useDocValuesAsStored="true"`. See <> & <> for more details. When `useDocValuesAsStored="false"`, non-stored DocValues fields can still be explicitly requested by name in the <>, but will not match glob patterns (`"*"`). Note that returning DocValues along with "regular" stored fields at query time has performance implications that stored fields may not because DocValues are column-oriented and may therefore incur additional cost to retrieve for each returned document. Also note that while returning non-stored fields from DocValues, the values of a multi-valued field are returned in sorted order rather than insertion order and may have duplicates removed, see above. If you require the multi-valued fields to be returned in the original insertion order, then make your multi-valued field as stored (such a change requires reindexing). In cases where the query is returning _only_ docValues fields performance may improve since returning stored fields requires disk reads and decompression whereas returning docValues fields in the fl list only requires memory access. -When retrieving fields from their docValues form (such as when using the <>, <> or if the field is requested in the `fl` parameter), two important differences between regular stored fields and docValues fields must be understood: +When retrieving fields from their docValues form (such as when using the <>, <> or if the field is requested in the `fl` parameter), two important differences between regular stored fields and docValues fields must be understood: 1. Order is _not_ preserved. When retrieving stored fields, the insertion order is the return order. For docValues, it is the _sorted_ order. 2. For field types using `SORTED_SET` (see above), multiple identical entries are collapsed into a single value. Thus if values 4, 5, 2, 4, 1 are inserted, the values returned will be 1, 2, 4, 5. diff --git a/solr/solr-ref-guide/src/enabling-ssl.adoc b/solr/solr-ref-guide/src/enabling-ssl.adoc index f8956740c35..bf681b20db8 100644 --- a/solr/solr-ref-guide/src/enabling-ssl.adoc +++ b/solr/solr-ref-guide/src/enabling-ssl.adoc @@ -71,7 +71,7 @@ To activate the SSL settings, uncomment and update the set of properties beginni ==== [.tab-label]**nix (solr.in.sh)* -NOTE: If you setup Solr as a service on Linux using the steps outlined in <>, then make these changes in `/var/solr/solr.in.sh`. +NOTE: If you setup Solr as a service on Linux using the steps outlined in <>, then make these changes in `/var/solr/solr.in.sh`. [source,bash] ---- @@ -195,7 +195,7 @@ NOTE: ZooKeeper does not support encrypted communication with clients like Solr. After creating the keystore described above and before you start any SolrCloud nodes, you must configure your Solr cluster properties in ZooKeeper so that Solr nodes know to communicate via SSL. This section assumes you have created and started an external ZooKeeper. -See <> for more information. +See <> for more information. The `urlScheme` cluster-wide property needs to be set to `https` before any Solr node starts up. The examples below use the `zkcli` tool that comes with Solr to do this. diff --git a/solr/solr-ref-guide/src/exporting-result-sets.adoc b/solr/solr-ref-guide/src/exporting-result-sets.adoc index cd3243176c9..a4da8234f01 100644 --- a/solr/solr-ref-guide/src/exporting-result-sets.adoc +++ b/solr/solr-ref-guide/src/exporting-result-sets.adoc @@ -17,7 +17,7 @@ // under the License. -It's possible to export fully sorted result sets using a special <> and <> specifically designed to work together to handle scenarios that involve sorting and exporting millions of records. +It's possible to export fully sorted result sets using a special <> and <> specifically designed to work together to handle scenarios that involve sorting and exporting millions of records. This feature uses a stream sorting technique that begins to send records within milliseconds and continues to stream results until the entire result set has been sorted and exported. @@ -25,11 +25,11 @@ The cases where this functionality may be useful include: session analysis, dist == Field Requirements -All the fields being sorted and exported must have docValues set to true. For more information, see the section on <>. +All the fields being sorted and exported must have docValues set to true. For more information, see the section on <>. == The /export RequestHandler -The `/export` request handler with the appropriate configuration is one of Solr's out-of-the-box request handlers - see <> for more information. +The `/export` request handler with the appropriate configuration is one of Solr's out-of-the-box request handlers - see <> for more information. Note that this request handler's properties are defined as "invariants", which means they cannot be overridden by other properties passed at another time (such as at query time). @@ -63,11 +63,11 @@ The `fl` property defines the fields that will be exported with the result set. === Specifying the Local Streaming Expression -The optional `expr` property defines a <> that allows documents to be processed locally before they are exported in the result set. +The optional `expr` property defines a <> that allows documents to be processed locally before they are exported in the result set. Expressions have to use a special `input()` stream that represents original results from the `/export` handler. Output from the stream expression then becomes the output from the `/export` handler. The `&streamLocalOnly=true` flag is always set for this streaming expression. -Only stream <> and <> are supported in these expressions - using any of the <> expressions except for the pre-defined `input()` will result in an error. +Only stream <> and <> are supported in these expressions - using any of the <> expressions except for the pre-defined `input()` will result in an error. Using stream expressions with the `/export` handler may result in dramatic performance improvements due to the local in-memory reduction of the number of documents to be returned. @@ -91,4 +91,4 @@ http://localhost:8983/solr/core_name/export?q=my-query&sort=reporter+desc,&fl=re == Distributed Support -See the section <> for distributed support. +See the section <> for distributed support. diff --git a/solr/solr-ref-guide/src/faceting.adoc b/solr/solr-ref-guide/src/faceting.adoc index 303e38c0cfa..a420c731f79 100644 --- a/solr/solr-ref-guide/src/faceting.adoc +++ b/solr/solr-ref-guide/src/faceting.adoc @@ -20,7 +20,7 @@ Faceting is the arrangement of search results into categories based on indexed t Searchers are presented with the indexed terms, along with numerical counts of how many matching documents were found for each term. Faceting makes it easy for users to explore search results, narrowing in on exactly the results they are looking for. -See also <> for an alternative approach to this. +See also <> for an alternative approach to this. == General Facet Parameters @@ -47,7 +47,7 @@ Several parameters can be used to trigger faceting based on the indexed terms in When using these parameters, it is important to remember that "term" is a very specific concept in Lucene: it relates to the literal field/value pairs that are indexed after any analysis occurs. For text fields that include stemming, lowercasing, or word splitting, the resulting terms may not be what you expect. If you want Solr to perform both analysis (for searching) and faceting on the full literal strings, use the `copyField` directive in your Schema to create two versions of the field: one Text and one String. The Text field should have `indexed="true" docValues=“false"` if used for searching but not faceting and the String field should have `indexed="false" docValues="true"` if used for faceting but not searching. -(For more information about the `copyField` directive, see <>.) +(For more information about the `copyField` directive, see <>.) Unless otherwise specified, all of the parameters below can be specified on a per-field basis with the syntax of `f..facet.` @@ -225,7 +225,7 @@ The `facet.range.method` parameter selects the type of algorithm or method Solr -- filter::: This method generates the ranges based on other facet.range parameters, and for each of them executes a filter that later intersects with the main query resultset to get the count. It will make use of the filterCache, so it will benefit of a cache large enough to contain all ranges. + -dv::: This method iterates the documents that match the main query, and for each of them finds the correct range for the value. This method will make use of <> (if enabled for the field) or fieldCache. The `dv` method is not supported for field type DateRangeField or when using <>. +dv::: This method iterates the documents that match the main query, and for each of them finds the correct range for the value. This method will make use of <> (if enabled for the field) or fieldCache. The `dv` method is not supported for field type DateRangeField or when using <>. -- + The default value for this parameter is `filter`. @@ -237,7 +237,7 @@ The default value for this parameter is `filter`. ==== Range faceting on date fields is a common situation where the <> parameter can be useful to ensure that the "facet counts per day" or "facet counts per month" are based on a meaningful definition of when a given day/month "starts" relative to a particular TimeZone. -For more information, see the examples in the <> section. +For more information, see the examples in the <> section. ==== === facet.mincount in Range Faceting @@ -295,7 +295,7 @@ http://localhost:8983/solr/techproducts/select?q=*:*&facet.pivot=cat,popularity, === Combining Stats Component With Pivots -In addition to some of the <> supported by other types of faceting, a `stats` local parameters can be used with `facet.pivot` to refer to <> instances (by tag) that you would like to have computed for each Pivot Constraint. +In addition to some of the <> supported by other types of faceting, a `stats` local parameters can be used with `facet.pivot` to refer to <> instances (by tag) that you would like to have computed for each Pivot Constraint. In the example below, two different (overlapping) sets of statistics are computed for each of the facet.pivot result hierarchies: @@ -526,7 +526,7 @@ Even though the same functionality can be achieved by using a facet query with r If you are concerned about the performance of your searches you should test with both options. Interval faceting tends to be better with multiple intervals for the same fields, while facet query tend to be better in environments where filter cache is more effective (static indexes for example). -This method will use <> if they are enabled for the field, will use fieldCache otherwise. +This method will use <> if they are enabled for the field, will use fieldCache otherwise. Use these parameters for interval faceting: @@ -575,7 +575,7 @@ Interval faceting supports output key replacement described below. Output keys c == Local Parameters for Faceting -The <> allows overriding global settings. It can also provide a method of adding metadata to other parameter values, much like XML attributes. +The <> allows overriding global settings. It can also provide a method of adding metadata to other parameter values, much like XML attributes. === Tagging and Excluding Filters @@ -622,4 +622,4 @@ This local parameter overrides default logic for `facet.sort`. if `facet.sort` i == Related Topics -See also <>. +See also <>. diff --git a/solr/solr-ref-guide/src/field-properties-by-use-case.adoc b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc index 11693d1df1c..4796f613e25 100644 --- a/solr/solr-ref-guide/src/field-properties-by-use-case.adoc +++ b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc @@ -42,8 +42,8 @@ Notes: 2. [[fpbuc_2,2]] Will be used if present, but not necessary. 3. [[fpbuc_3,3]] (if termVectors=true) 4. [[fpbuc_4,4]] A tokenizer must be defined for the field, but it doesn't need to be indexed. -5. [[fpbuc_5,5]] Described in <>. +5. [[fpbuc_5,5]] Described in <>. 6. [[fpbuc_6,6]] Term vectors are not mandatory here. If not true, then a stored field is analyzed. So term vectors are recommended, but only required if `stored=false`. -7. [[fpbuc_7,7]] For most field types, either `indexed` or `docValues` must be true, but both are not required. <> can be more efficient in many cases. For `[Int/Long/Float/Double/Date]PointFields`, `docValues=true` is required. -8. [[fpbuc_8,8]] Stored content will be used by default, but docValues can alternatively be used. See <>. +7. [[fpbuc_7,7]] For most field types, either `indexed` or `docValues` must be true, but both are not required. <> can be more efficient in many cases. For `[Int/Long/Float/Double/Date]PointFields`, `docValues=true` is required. +8. [[fpbuc_8,8]] Stored content will be used by default, but docValues can alternatively be used. See <>. 9. [[fpbuc_9,9]] Multi-valued sorting may be performed on docValues-enabled fields using the two-argument `field()` function, e.g., `field(myfield,min)`; see the <>. 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 487cd4c348a..91e44167172 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 @@ -50,7 +50,7 @@ Field types are defined in `schema.xml`. Each field type is defined between `fie ---- <1> The first line in the example above contains the field type name, `text_general`, and the name of the implementing class, `solr.TextField`. -<2> The rest of the definition is about field analysis, described in <>. +<2> The rest of the definition is about field analysis, described in <>. The implementing class is responsible for making sure the field is handled correctly. In the class names in `schema.xml`, the string `solr` is shorthand for `org.apache.solr.schema` or `org.apache.solr.analysis`. Therefore, `solr.TextField` is really `org.apache.solr.schema.TextField`. @@ -127,16 +127,16 @@ The default values for each property depend on the underlying `FieldType` class, |Property |Description |Values |Implicit Default |indexed |If true, the value of the field can be used in queries to retrieve matching documents. |true or false |true |stored |If true, the actual value of the field can be retrieved by queries. |true or false |true -|docValues |If true, the value of the field will be put in a column-oriented <> structure. |true or false |false +|docValues |If true, the value of the field will be put in a column-oriented <> structure. |true or false |false |sortMissingFirst sortMissingLast |Control the placement of documents when a sort field is not present. |true or false |false |multiValued |If true, indicates that a single document might contain multiple values for this field type. |true or false |false -|uninvertible|If true, indicates that an `indexed="true" docValues="false"` field can be "un-inverted" at query time to build up large in memory data structure to serve in place of <>. *Defaults to true for historical reasons, but users are strongly encouraged to set this to `false` for stability and use `docValues="true"` as needed.*|true or false |true +|uninvertible|If true, indicates that an `indexed="true" docValues="false"` field can be "un-inverted" at query time to build up large in memory data structure to serve in place of <>. *Defaults to true for historical reasons, but users are strongly encouraged to set this to `false` for stability and use `docValues="true"` as needed.*|true or false |true |omitNorms |If true, omits the norms associated with this field (this disables length normalization for the field, and saves some memory). *Defaults to true for all primitive (non-analyzed) field types, such as int, float, data, bool, and string.* Only full-text fields or fields need norms. |true or false |* |omitTermFreqAndPositions |If true, omits term frequency, positions, and payloads from postings for this field. This can be a performance boost for fields that don't require that information. It also reduces the storage space required for the index. Queries that rely on position that are issued on a field with this option will silently fail to find documents. *This property defaults to true for all field types that are not text fields.* |true or false |* |omitPositions |Similar to `omitTermFreqAndPositions` but preserves term frequency information. |true or false |* |termVectors termPositions termOffsets termPayloads |These options instruct Solr to maintain full term vectors for each document, optionally including position, offset and payload information for each term occurrence in those vectors. These can be used to accelerate highlighting and other ancillary functionality, but impose a substantial cost in terms of index size. They are not necessary for typical uses of Solr. |true or false |false |required |Instructs Solr to reject any attempts to add a document which does not have a value for this field. This property defaults to false. |true or false |false -|useDocValuesAsStored |If the field has <> enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <>. |true or false |true +|useDocValuesAsStored |If the field has <> enabled, setting this to true would allow the field to be returned as if it were a stored field (even if it has `stored=false`) when matching "`*`" in an <>. |true or false |true |large |Large fields are always lazy loaded and will only take up space in the document cache if the actual value is < 512KB. This option requires `stored="true"` and `multiValued="false"`. It's intended for fields that might have very large values so that they don't get cached in memory. |true or false |false |=== diff --git a/solr/solr-ref-guide/src/field-types-included-with-solr.adoc b/solr/solr-ref-guide/src/field-types-included-with-solr.adoc index cbeeafa0f22..a2b8be9b833 100644 --- a/solr/solr-ref-guide/src/field-types-included-with-solr.adoc +++ b/solr/solr-ref-guide/src/field-types-included-with-solr.adoc @@ -25,7 +25,7 @@ The following table lists the field types that are available in Solr and are rec [cols="25,75",options="header"] |=== |Class |Description -|BBoxField | Indexes a single rectangle (bounding box) per document field and supports searching via a bounding box. See the section <> for more information. +|BBoxField | Indexes a single rectangle (bounding box) per document field and supports searching via a bounding box. See the section <> for more information. |BinaryField |Binary data. @@ -33,17 +33,17 @@ The following table lists the field types that are available in Solr and are rec |CollationField |Supports Unicode collation for sorting and range queries. The ICUCollationField is a better choice if you can use ICU4J. See the section <> for more information. -|CurrencyFieldType |Supports currencies and exchange rates. See the section <> for more information. +|CurrencyFieldType |Supports currencies and exchange rates. See the section <> for more information. -|DateRangeField |Supports indexing date ranges, to include point in time date instances as well (single-millisecond durations). See the section <> for more detail on using this field type. Consider using this field type even if it's just for date instances, particularly when the queries typically fall on UTC year/month/day/hour, etc., boundaries. +|DateRangeField |Supports indexing date ranges, to include point in time date instances as well (single-millisecond durations). See the section <> for more detail on using this field type. Consider using this field type even if it's just for date instances, particularly when the queries typically fall on UTC year/month/day/hour, etc., boundaries. -|DatePointField |Date field. Represents a point in time with millisecond precision, encoded using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. See the section <> for more details on the supported syntax. For single valued fields, `docValues="true"` must be used to enable sorting. +|DatePointField |Date field. Represents a point in time with millisecond precision, encoded using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. See the section <> for more details on the supported syntax. For single valued fields, `docValues="true"` must be used to enable sorting. |DoublePointField |Double field (64-bit IEEE floating point). This class encodes double values using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. For single valued fields, `docValues="true"` must be used to enable sorting. -|ExternalFileField |Pulls values from a file on disk. See the section <> for more information. +|ExternalFileField |Pulls values from a file on disk. See the section <> for more information. -|EnumFieldType |Allows defining an enumerated set of values which may not be easily sorted by either alphabetic or numeric order (such as a list of severities, for example). This field type takes a configuration file, which lists the proper order of the field values. See the section <> for more information. +|EnumFieldType |Allows defining an enumerated set of values which may not be easily sorted by either alphabetic or numeric order (such as a list of severities, for example). This field type takes a configuration file, which lists the proper order of the field values. See the section <> for more information. |FloatPointField |Floating point field (32-bit IEEE floating point). This class encodes float values using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. For single valued fields, `docValues="true"` must be used to enable sorting. @@ -51,13 +51,13 @@ The following table lists the field types that are available in Solr and are rec |IntPointField |Integer field (32-bit signed integer). This class encodes int values using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. For single valued fields, `docValues="true"` must be used to enable sorting. -|LatLonPointSpatialField |A latitude/longitude coordinate pair; possibly multi-valued for multiple points. Usually it's specified as "lat,lon" order with a comma. See the section <> for more information. +|LatLonPointSpatialField |A latitude/longitude coordinate pair; possibly multi-valued for multiple points. Usually it's specified as "lat,lon" order with a comma. See the section <> for more information. |LongPointField |Long field (64-bit signed integer). This class encodes foo values using a "Dimensional Points" based data structure that allows for very efficient searches for specific values, or ranges of values. For single valued fields, `docValues="true"` must be used to enable sorting. |NestPathField | Specialized field type storing ehanced information, when <>. -|PointType |A single-valued n-dimensional point. It's both for sorting spatial data that is _not_ lat-lon, and for some more rare use-cases. (NOTE: this is _not_ related to the "Point" based numeric fields). See <> for more information. +|PointType |A single-valued n-dimensional point. It's both for sorting spatial data that is _not_ lat-lon, and for some more rare use-cases. (NOTE: this is _not_ related to the "Point" based numeric fields). See <> for more information. |PreAnalyzedField |Provides a way to send to Solr serialized token streams, optionally with independent stored values of a field, and have this information stored and indexed without any additional text processing. @@ -67,19 +67,19 @@ Configuration and usage of PreAnalyzedField is documented in the section <> -|RptWithGeometrySpatialField |A derivative of `SpatialRecursivePrefixTreeFieldType` that also stores the original geometry. See <> for more information and usage with geospatial results transformer. +|RptWithGeometrySpatialField |A derivative of `SpatialRecursivePrefixTreeFieldType` that also stores the original geometry. See <> for more information and usage with geospatial results transformer. |SortableTextField |A specialized version of TextField that allows (and defaults to) `docValues="true"` for sorting on the first 1024 characters of the original string prior to analysis. The number of characters used for sorting can be overridden with the `maxCharsForDocValues` attribute. See <> for details. -|SpatialRecursivePrefixTreeFieldType |(RPT for short) Accepts latitude comma longitude strings or other shapes in WKT format. See <> for more information. +|SpatialRecursivePrefixTreeFieldType |(RPT for short) Accepts latitude comma longitude strings or other shapes in WKT format. See <> for more information. |StrField |String (UTF-8 encoded string or Unicode). Strings are intended for small fields and are _not_ tokenized or analyzed in any way. They have a hard limit of slightly less than 32K. -|TextField |Text, usually multiple words or tokens. In normal usage, only fields of type TextField or SortableTextField will specify an <>. +|TextField |Text, usually multiple words or tokens. In normal usage, only fields of type TextField or SortableTextField will specify an <>. |UUIDField |Universally Unique Identifier (UUID). Pass in a value of `NEW` and Solr will create a new UUID. -*Note*: configuring a UUIDField instance with a default value of `NEW` is not advisable for most users when using SolrCloud (and not possible if the UUID value is configured as the unique key field) since the result will be that each replica of each document will get a unique UUID value. Using <> to generate UUID values when documents are added is recommended instead. +*Note*: configuring a UUIDField instance with a default value of `NEW` is not advisable for most users when using SolrCloud (and not possible if the UUID value is configured as the unique key field) since the result will be that each replica of each document will get a unique UUID value. Using <> to generate UUID values when documents are added is recommended instead. |=== == Deprecated Field Types @@ -97,7 +97,7 @@ NOTE: All Trie* numeric and date field types have been deprecated in favor of *P |EnumField |Use EnumFieldType instead. -|LatLonType |Consider using the LatLonPointSpatialField instead. A single-valued latitude/longitude coordinate pair. Usually it's specified as "lat,lon" order with a comma. See the section <> for more information. +|LatLonType |Consider using the LatLonPointSpatialField instead. A single-valued latitude/longitude coordinate pair. Usually it's specified as "lat,lon" order with a comma. See the section <> for more information. |TrieDateField |Use DatePointField instead. diff --git a/solr/solr-ref-guide/src/files-screen.adoc b/solr/solr-ref-guide/src/files-screen.adoc index 6fd417a37fd..57be896f169 100644 --- a/solr/solr-ref-guide/src/files-screen.adoc +++ b/solr/solr-ref-guide/src/files-screen.adoc @@ -21,17 +21,17 @@ The Files screen lets you browse & view the various configuration files (such `s .The Files Screen image::images/files-screen/files-screen.png[image,height=400] -If you are using <>, the files displayed are the configuration files for this collection stored in ZooKeeper. In a standalone Solr installations, all files in the `conf` directory are displayed. +If you are using <>, the files displayed are the configuration files for this collection stored in ZooKeeper. In a standalone Solr installations, all files in the `conf` directory are displayed. While `solrconfig.xml` defines the behavior of Solr as it indexes content and responds to queries, the Schema allows you to define the types of data in your content (field types), the fields your documents will be broken into, and any dynamic fields that should be generated based on patterns of field names in the incoming documents. Any other configuration files are used depending on how they are referenced in either `solrconfig.xml` or your schema. Configuration files cannot be edited with this screen, so a text editor of some kind must be used. -This screen is related to the <>, in that they both can display information from the schema, but the Schema Browser provides a way to drill into the analysis chain and displays linkages between field types, fields, and dynamic field rules. +This screen is related to the <>, in that they both can display information from the schema, but the Schema Browser provides a way to drill into the analysis chain and displays linkages between field types, fields, and dynamic field rules. Many of the options defined in these configuration files are described throughout the rest of this Guide. In particular, you will want to review these sections: -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> diff --git a/solr/solr-ref-guide/src/filter-descriptions.adoc b/solr/solr-ref-guide/src/filter-descriptions.adoc index 07643dcc64f..2c059d202a0 100644 --- a/solr/solr-ref-guide/src/filter-descriptions.adoc +++ b/solr/solr-ref-guide/src/filter-descriptions.adoc @@ -292,7 +292,7 @@ Collation allows sorting of text in a language-sensitive way. It is usually used == Daitch-Mokotoff Soundex Filter -Implements the Daitch-Mokotoff Soundex algorithm, which allows identification of similar names, even if they are spelled differently. More information about how this works is available in the section on <>. +Implements the Daitch-Mokotoff Soundex algorithm, which allows identification of similar names, even if they are spelled differently. More information about how this works is available in the section on <>. *Factory class:* `solr.DaitchMokotoffSoundexFilterFactory` @@ -330,7 +330,7 @@ Implements the Daitch-Mokotoff Soundex algorithm, which allows identification of == Double Metaphone Filter -This filter creates tokens using the http://commons.apache.org/proper/commons-codec/archives/{ivy-commons-codec-version}/apidocs/org/apache/commons/codec/language/DoubleMetaphone.html[`DoubleMetaphone`] encoding algorithm from commons-codec. For more information, see the <> section. +This filter creates tokens using the http://commons.apache.org/proper/commons-codec/archives/{ivy-commons-codec-version}/apidocs/org/apache/commons/codec/language/DoubleMetaphone.html[`DoubleMetaphone`] encoding algorithm from commons-codec. For more information, see the <> section. *Factory class:* `solr.DoubleMetaphoneFilterFactory` @@ -1343,7 +1343,7 @@ Converts any uppercase letters in a token to the equivalent lowercase token. All == Managed Stop Filter -This is specialized version of the <> that uses a set of stop words that are <> +This is specialized version of the <> that uses a set of stop words that are <> *Arguments:* @@ -1383,7 +1383,7 @@ See <> for example input/output. == Managed Synonym Filter -This is specialized version of the <> that uses a mapping on synonyms that is <> +This is specialized version of the <> that uses a mapping on synonyms that is <> .Managed Synonym Filter has been Deprecated [WARNING] @@ -1397,7 +1397,7 @@ For arguments and examples, see the <> below. == Managed Synonym Graph Filter -This is specialized version of the <> that uses a mapping on synonyms that is <> +This is specialized version of the <> that uses a mapping on synonyms that is <> This filter maps single- or multi-token synonyms, producing a fully correct graph output. This filter is a replacement for the Managed Synonym Filter, which produces incorrect graphs for multi-token synonyms. @@ -1687,7 +1687,7 @@ More complex pattern with capture group reference in the replacement. Tokens tha == Phonetic Filter -This filter creates tokens using one of the phonetic encoding algorithms in the `org.apache.commons.codec.language` package. For more information, see the section on <>. +This filter creates tokens using one of the phonetic encoding algorithms in the `org.apache.commons.codec.language` package. For more information, see the section on <>. *Factory class:* `solr.PhoneticFilterFactory` @@ -2314,7 +2314,7 @@ NOTE: Although this filter produces correct token graphs, it cannot consume an i *Arguments:* -`synonyms`:: (required) The path of a file that contains a list of synonyms, one per line. In the (default) `solr` format - see the `format` argument below for alternatives - blank lines and lines that begin with "`#`" are ignored. This may be a comma-separated list of paths. See <> for more information. +`synonyms`:: (required) The path of a file that contains a list of synonyms, one per line. In the (default) `solr` format - see the `format` argument below for alternatives - blank lines and lines that begin with "`#`" are ignored. This may be a comma-separated list of paths. See <> for more information. + There are two ways to specify synonym mappings: + diff --git a/solr/solr-ref-guide/src/format-of-solr-xml.adoc b/solr/solr-ref-guide/src/format-of-solr-xml.adoc index 6416c6c7ea0..458b936e71b 100644 --- a/solr/solr-ref-guide/src/format-of-solr-xml.adoc +++ b/solr/solr-ref-guide/src/format-of-solr-xml.adoc @@ -18,7 +18,7 @@ The `solr.xml` file defines some global configuration options that apply to all or many cores. -This section will describe the default `solr.xml` file included with Solr and how to modify it for your needs. For details on how to configure `core.properties`, see the section <>. +This section will describe the default `solr.xml` file included with Solr and how to modify it for your needs. For details on how to configure `core.properties`, see the section <>. == Defining solr.xml @@ -160,7 +160,7 @@ In SolrCloud mode, the URL of the ZooKeeper host that Solr should use for cluste If `TRUE`, node names are not based on the address of the node, but on a generic name that identifies the core. When a different machine takes over serving that core things will be much easier to understand. `zkCredentialsProvider` & `zkACLProvider`:: -Optional parameters that can be specified if you are using <>. +Optional parameters that can be specified if you are using <>. === The Element diff --git a/solr/solr-ref-guide/src/function-queries.adoc b/solr/solr-ref-guide/src/function-queries.adoc index 13ffa460e85..8dfb206c116 100644 --- a/solr/solr-ref-guide/src/function-queries.adoc +++ b/solr/solr-ref-guide/src/function-queries.adoc @@ -18,7 +18,7 @@ Function queries enable you to generate a relevancy score using the actual value of one or more numeric fields. -Function queries are supported by the <>, <>, and <> query parsers. +Function queries are supported by the <>, <>, and <> query parsers. Function queries use _functions_. The functions can be a constant (numeric or string literal), a field, another function or a parameter substitution argument. You can use these functions to modify the ranking of results for users. These could be used to change the ranking of results based on a user's location, or some other calculation. @@ -253,7 +253,7 @@ Use the `field(myfield,min)` <>. +Arguments may be the name of a `DatePointField`, `TrieDateField`, or date math based on a <>. * `ms()`: Equivalent to `ms(NOW)`, number of milliseconds since the epoch. * `ms(a):` Returns the number of milliseconds since the epoch that the argument represents. @@ -332,7 +332,7 @@ Returns the product of multiple values or functions, which are specified in a co * `mul(x,y)` === query Function -Returns the score for the given subquery, or the default value for documents not matching the query. Any type of subquery is supported through either parameter de-referencing `$otherparam` or direct specification of the query string in the <> through the `v` key. +Returns the score for the given subquery, or the default value for documents not matching the query. Any type of subquery is supported through either parameter de-referencing `$otherparam` or direct specification of the query string in the <> through the `v` key. *Syntax Examples* diff --git a/solr/solr-ref-guide/src/getting-started-with-solrcloud.adoc b/solr/solr-ref-guide/src/getting-started-with-solrcloud.adoc index c2e60144adf..a5451713985 100644 --- a/solr/solr-ref-guide/src/getting-started-with-solrcloud.adoc +++ b/solr/solr-ref-guide/src/getting-started-with-solrcloud.adoc @@ -28,7 +28,7 @@ In this section you will learn how to start a SolrCloud cluster using startup sc [TIP] ==== -This tutorial assumes that you're already familiar with the basics of using Solr. If you need a refresher, please see the <> to get a grounding in Solr concepts. If you load documents as part of that exercise, you should start over with a fresh Solr installation for these SolrCloud tutorials. +This tutorial assumes that you're already familiar with the basics of using Solr. If you need a refresher, please see the <> to get a grounding in Solr concepts. If you load documents as part of that exercise, you should start over with a fresh Solr installation for these SolrCloud tutorials. ==== [WARNING] @@ -86,9 +86,9 @@ After starting up all nodes in the cluster, the script prompts you for the name The suggested default is "gettingstarted" but you might want to choose a name more appropriate for your specific search application. -Next, the script prompts you for the number of shards to distribute the collection across. <> is covered in more detail later on, so if you're unsure, we suggest using the default of 2 so that you can see how a collection is distributed across multiple nodes in a SolrCloud cluster. +Next, the script prompts you for the number of shards to distribute the collection across. <> is covered in more detail later on, so if you're unsure, we suggest using the default of 2 so that you can see how a collection is distributed across multiple nodes in a SolrCloud cluster. -Next, the script will prompt you for the number of replicas to create for each shard. <> is covered in more detail later in the guide, so if you're unsure, then use the default of 2 so that you can see how replication is handled in SolrCloud. +Next, the script will prompt you for the number of replicas to create for each shard. <> is covered in more detail later in the guide, so if you're unsure, then use the default of 2 so that you can see how replication is handled in SolrCloud. Lastly, the script will prompt you for the name of a configuration directory for your collection. You can choose *_default*, or *sample_techproducts_configs*. The configuration directories are pulled from `server/solr/configsets/` so you can review them beforehand if you wish. The *_default* configuration is useful when you're still designing a schema for your documents and need some flexibility as you experiment with Solr, since it has schemaless functionality. However, after creating your collection, the schemaless functionality can be disabled in order to lock down the schema (so that documents indexed after doing so will not alter the schema) or to configure the schema by yourself. This can be done as follows (assuming your collection name is `mycollection`): @@ -131,7 +131,7 @@ bin/solr healthcheck -c gettingstarted The healthcheck command gathers basic information about each replica in a collection, such as number of docs, current status (active, down, etc.), and address (where the replica lives in the cluster). -Documents can now be added to SolrCloud using the <>. +Documents can now be added to SolrCloud using the <>. To stop Solr in SolrCloud mode, you would use the `bin/solr` script and issue the `stop` command, as in: @@ -191,4 +191,4 @@ bin/solr start -cloud -s example/cloud/node3/solr -p 8987 -z localhost:9983 The previous command will start another Solr node on port 8987 with Solr home set to `example/cloud/node3/solr`. The new node will write its log files to `example/cloud/node3/logs`. -Once you're comfortable with how the SolrCloud example works, we recommend using the process described in <> for setting up SolrCloud nodes in production. +Once you're comfortable with how the SolrCloud example works, we recommend using the process described in <> for setting up SolrCloud nodes in production. diff --git a/solr/solr-ref-guide/src/getting-started.adoc b/solr/solr-ref-guide/src/getting-started.adoc index 90e8ba0f883..c3bf8b58c82 100644 --- a/solr/solr-ref-guide/src/getting-started.adoc +++ b/solr/solr-ref-guide/src/getting-started.adoc @@ -22,10 +22,10 @@ Solr makes it easy for programmers to develop sophisticated, high-performance se This section introduces you to the basic Solr architecture and features to help you get up and running quickly. It covers the following topics: -<>: This tutorial covers getting Solr up and running +<>: This tutorial covers getting Solr up and running -<>: A high-level overview of how Solr works. +<>: A high-level overview of how Solr works. -<>: Solr System Requirement +<>: Solr System Requirement -<>: A walkthrough of the Solr installation process. +<>: A walkthrough of the Solr installation process. diff --git a/solr/solr-ref-guide/src/graph-traversal.adoc b/solr/solr-ref-guide/src/graph-traversal.adoc index 9056f381f15..c46eb353496 100644 --- a/solr/solr-ref-guide/src/graph-traversal.adoc +++ b/solr/solr-ref-guide/src/graph-traversal.adoc @@ -26,7 +26,7 @@ The `nodes` function can be combined with the `scoreNodes` function to provide r [IMPORTANT] ==== -This document assumes a basic understanding of graph terminology and streaming expressions. You can begin exploring graph traversal concepts with this https://en.wikipedia.org/wiki/Graph_traversal[Wikipedia article]. More details about streaming expressions are available in this Guide, in the section <>. +This document assumes a basic understanding of graph terminology and streaming expressions. You can begin exploring graph traversal concepts with this https://en.wikipedia.org/wiki/Graph_traversal[Wikipedia article]. More details about streaming expressions are available in this Guide, in the section <>. ==== == Basic Syntax @@ -59,7 +59,7 @@ nodes(emails, The `nodes` function above finds all the edges with "johndoe@apache.org" or "janesmith@apache.org" in the `from` field and gathers the `to` field. -Like all <>, you can execute a `nodes` expression by sending it to the `/stream` handler. For example: +Like all <>, you can execute a `nodes` expression by sending it to the `/stream` handler. For example: [source,bash] ---- @@ -220,7 +220,7 @@ nodes(emails, gather="to") ---- -In the example above only emails that match the filter query will be included in the traversal. Any Solr query can be included here. So you can do fun things like <>, apply any of the available <>, or even write custom query parsers to limit the traversal. +In the example above only emails that match the filter query will be included in the traversal. Any Solr query can be included here. So you can do fun things like <>, apply any of the available <>, or even write custom query parsers to limit the traversal. == Root Streams diff --git a/solr/solr-ref-guide/src/hadoop-authentication-plugin.adoc b/solr/solr-ref-guide/src/hadoop-authentication-plugin.adoc index d51935c4e00..96609c07902 100644 --- a/solr/solr-ref-guide/src/hadoop-authentication-plugin.adoc +++ b/solr/solr-ref-guide/src/hadoop-authentication-plugin.adoc @@ -24,7 +24,7 @@ This plugin can be particularly useful in leveraging an extended set of features Please note that the version of Hadoop library used by Solr is upgraded periodically. While Solr will ensure the stability and backwards compatibility of the structure of the plugin configuration (viz., the parameter names of this plugin), the values of these parameters may change based on the version of Hadoop library. Please review the Hadoop documentation for the version used by your Solr installation for more details. -For some of the authentication schemes (e.g., Kerberos), Solr provides a native implementation of authentication plugin. If you require a more stable setup, in terms of configuration, ability to perform rolling upgrades, backward compatibility, etc., you should consider using such plugin. Please review the section <> for an overview of authentication plugin options in Solr. +For some of the authentication schemes (e.g., Kerberos), Solr provides a native implementation of authentication plugin. If you require a more stable setup, in terms of configuration, ability to perform rolling upgrades, backward compatibility, etc., you should consider using such plugin. Please review the section <> for an overview of authentication plugin options in Solr. There are two plugin classes: @@ -71,9 +71,9 @@ The `HttpClientBuilderFactory` implementation used for the Solr internal communi === Kerberos Authentication using Hadoop Authentication Plugin -This example lets you configure Solr to use Kerberos Authentication, similar to how you would use the <>. +This example lets you configure Solr to use Kerberos Authentication, similar to how you would use the <>. -After consulting the Hadoop authentication library's documentation, you can supply per host configuration parameters using the `solr.*` prefix. As an example, the Hadoop authentication library expects a parameter `kerberos.principal`, which can be supplied as a system property named `solr.kerberos.principal` when starting a Solr node. Refer to the section <> for other typical configuration parameters. +After consulting the Hadoop authentication library's documentation, you can supply per host configuration parameters using the `solr.*` prefix. As an example, the Hadoop authentication library expects a parameter `kerberos.principal`, which can be supplied as a system property named `solr.kerberos.principal` when starting a Solr node. Refer to the section <> for other typical configuration parameters. Please note that this example uses `ConfigurableInternodeAuthHadoopPlugin`, and hence you must provide the `clientBuilderFactory` implementation. As a result, all internode communication will use the Kerberos mechanism, instead of PKI authentication. @@ -101,7 +101,7 @@ To setup this plugin, use the following in your `security.json` file. === Simple Authentication with Delegation Tokens -Similar to the previous example, this is an example of setting up a Solr cluster that uses delegation tokens. Refer to the parameters in the Hadoop authentication library's https://hadoop.apache.org/docs/stable/hadoop-auth/Configuration.html[documentation] or refer to the section <> for further details. Please note that this example does not use Kerberos and the requests made to Solr must contain valid delegation tokens. +Similar to the previous example, this is an example of setting up a Solr cluster that uses delegation tokens. Refer to the parameters in the Hadoop authentication library's https://hadoop.apache.org/docs/stable/hadoop-auth/Configuration.html[documentation] or refer to the section <> for further details. Please note that this example does not use Kerberos and the requests made to Solr must contain valid delegation tokens. To setup this plugin, use the following in your `security.json` file. diff --git a/solr/solr-ref-guide/src/highlighting.adoc b/solr/solr-ref-guide/src/highlighting.adoc index 9fe6c89c512..edd02282cb4 100644 --- a/solr/solr-ref-guide/src/highlighting.adoc +++ b/solr/solr-ref-guide/src/highlighting.adoc @@ -42,7 +42,7 @@ When using `*`, consider adding `hl.requireFieldMatch=true`. + Note that the field(s) listed here ought to have compatible text-analysis (defined in the schema) with field(s) referenced in the query to be highlighted. It may be necessary to modify `hl.q` and `hl.qparser` and/or modify the text analysis. -The following example uses the <> syntax and <> to highlight fields in `hl.fl`: +The following example uses the <> syntax and <> to highlight fields in `hl.fl`: `&hl.fl=field1 field2&hl.q={!edismax qf=$hl.fl v=$q}&hl.qparser=lucene&hl.requireFieldMatch=true` (along with other applicable parameters, of course). + The default is the value of the `df` parameter which in turn has no default. @@ -55,7 +55,7 @@ When setting this, you might also need to set `hl.qparser`. The default is the value of the `q` parameter (already parsed). `hl.qparser`:: -The <> to use for the `hl.q` query. It only applies when `hl.q` is set. +The <> to use for the `hl.q` query. It only applies when `hl.q` is set. + The default is the value of the `defType` parameter which in turn defaults to `lucene`. diff --git a/solr/solr-ref-guide/src/how-solrcloud-works.adoc b/solr/solr-ref-guide/src/how-solrcloud-works.adoc index 84c47ae649a..19359084cc4 100644 --- a/solr/solr-ref-guide/src/how-solrcloud-works.adoc +++ b/solr/solr-ref-guide/src/how-solrcloud-works.adoc @@ -19,11 +19,11 @@ The following sections cover provide general information about how various SolrCloud features work. To understand these features, it's important to first understand a few key concepts that relate to SolrCloud. -* <> -* <> -* <> +* <> +* <> +* <> -If you are already familiar with SolrCloud concepts and basic functionality, you can skip to the section covering <>. +If you are already familiar with SolrCloud concepts and basic functionality, you can skip to the section covering <>. == Key SolrCloud Concepts diff --git a/solr/solr-ref-guide/src/implicit-requesthandlers.adoc b/solr/solr-ref-guide/src/implicit-requesthandlers.adoc index 76fa4acbdd7..b8d711cf032 100644 --- a/solr/solr-ref-guide/src/implicit-requesthandlers.adoc +++ b/solr/solr-ref-guide/src/implicit-requesthandlers.adoc @@ -61,7 +61,7 @@ v2: `api/node/logging` |{solr-javadocs}/core/org/apache/solr/handler/admin/ShowF Luke:: Expose the internal Lucene index. This handler must have a collection name in the path to the endpoint. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -72,7 +72,7 @@ Luke:: Expose the internal Lucene index. This handler must have a collection nam MBeans:: Provide info about all registered {solr-javadocs}/core/org/apache/solr/core/SolrInfoBean.html[SolrInfoMBeans]. This handler must have a collection name in the path to the endpoint. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -82,7 +82,7 @@ MBeans:: Provide info about all registered {solr-javadocs}/core/org/apache/solr/ Ping:: Health check. This handler must have a collection name in the path to the endpoint. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -151,7 +151,7 @@ Document Analysis:: Return a breakdown of the analysis process of the given docu |`solr//analysis/document` |{solr-javadocs}/core/org/apache/solr/handler/DocumentAnalysisRequestHandler.html[DocumentAnalysisRequestHandler] |`_ANALYSIS_DOCUMENT` |=== -Field Analysis:: Return index- and query-time analysis over the given field(s)/field type(s). This handler drives the <> in Solr's Admin UI. +Field Analysis:: Return index- and query-time analysis over the given field(s)/field type(s). This handler drives the <> in Solr's Admin UI. + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -164,7 +164,7 @@ Field Analysis:: Return index- and query-time analysis over the given field(s)/f [horizontal] Config API:: Retrieve and modify Solr configuration. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -192,7 +192,7 @@ Replication:: Replicate indexes for SolrCloud recovery and Leader/Follower index Schema API:: Retrieve and modify the Solr schema. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -207,7 +207,7 @@ v2: `api/collections//schema`, `api/cores//schema` |{solr-java [horizontal] Export:: Export full sorted result sets. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -217,7 +217,7 @@ Export:: Export full sorted result sets. RealTimeGet:: Low-latency retrieval of the latest version of a document. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -227,7 +227,7 @@ RealTimeGet:: Low-latency retrieval of the latest version of a document. Graph Traversal:: Return http://graphml.graphdrawing.org/[GraphML] formatted output from a `gatherNodes` streaming expression. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -270,7 +270,7 @@ Terms:: Return a field's indexed terms and the number of documents containing ea [horizontal] Update:: Add, delete and update indexed documents formatted as SolrXML, CSV, SolrJSON or javabin. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -300,7 +300,7 @@ JSON Updates:: Add, delete and update SolrJSON-formatted documents. Custom JSON Updates:: Add and update custom JSON-formatted documents. + -*Documentation*: <> +*Documentation*: <> + [cols="3*.",frame=none,grid=cols,options="header"] |=== @@ -310,7 +310,7 @@ Custom JSON Updates:: Add and update custom JSON-formatted documents. == How to View Implicit Handler Paramsets -You can see configuration for all request handlers, including the implicit request handlers, via the <>. +You can see configuration for all request handlers, including the implicit request handlers, via the <>. To include the expanded paramset in the response, as well as the effective parameters from merging the paramset parameters with the built-in parameters, use the `expandParams` request parameter. For the `/export` request handler, you can make a request like this: @@ -374,4 +374,4 @@ The response will look similar to: == How to Edit Implicit Handler Paramsets -Because implicit request handlers are not present in `solrconfig.xml`, configuration of their associated `default`, `invariant` and `appends` parameters may be edited via the <> using the paramset listed in the above table. However, other parameters, including SearchHandler components, may not be modified. The invariants and appends specified in the implicit configuration cannot be overridden. +Because implicit request handlers are not present in `solrconfig.xml`, configuration of their associated `default`, `invariant` and `appends` parameters may be edited via the <> using the paramset listed in the above table. However, other parameters, including SearchHandler components, may not be modified. The invariants and appends specified in the implicit configuration cannot be overridden. diff --git a/solr/solr-ref-guide/src/index-replication.adoc b/solr/solr-ref-guide/src/index-replication.adoc index 000821e174d..961cb249838 100644 --- a/solr/solr-ref-guide/src/index-replication.adoc +++ b/solr/solr-ref-guide/src/index-replication.adoc @@ -38,7 +38,7 @@ Solr includes a Java implementation of index replication that works over HTTP: .Replication In SolrCloud [NOTE] ==== -Although there is no explicit concept of "leader/follower" nodes in a <> cluster, the `ReplicationHandler` discussed on this page is still used by SolrCloud as needed to support "shard recovery" – but this is done in a peer to peer manner. +Although there is no explicit concept of "leader/follower" nodes in a <> cluster, the `ReplicationHandler` discussed on this page is still used by SolrCloud as needed to support "shard recovery" – but this is done in a peer to peer manner. When using SolrCloud, the `ReplicationHandler` must be available via the `/replication` path. Solr does this implicitly unless overridden explicitly in your `solrconfig.xml`, but if you wish to override the default behavior, make certain that you do not explicitly set any of the "leader" or "follower" configuration options mentioned below, or they will interfere with normal SolrCloud operation. ==== diff --git a/solr/solr-ref-guide/src/index.adoc b/solr/solr-ref-guide/src/index.adoc index eccd0027643..789c546f861 100644 --- a/solr/solr-ref-guide/src/index.adoc +++ b/solr/solr-ref-guide/src/index.adoc @@ -66,18 +66,18 @@ The Guide includes the following sections: [sidebar.col] **** -The *<>* section guides you through the installation and setup of Solr. A detailed tutorial for first-time users shows many of Solr's features. +The *<>* section guides you through the installation and setup of Solr. A detailed tutorial for first-time users shows many of Solr's features. -*<>*: This section introduces the Web-based interface for administering Solr. From your browser you can view configuration files, submit queries, view logfile settings and Java environment settings, and monitor and control distributed configurations. +*<>*: This section introduces the Web-based interface for administering Solr. From your browser you can view configuration files, submit queries, view logfile settings and Java environment settings, and monitor and control distributed configurations. **** .Deploying Solr [sidebar.col] **** -*<>*: Once you have Solr configured, you want to deploy it to production and keep it up to date. This section includes information about how to take Solr to production, run it in HDFS or AWS, and information about upgrades and managing Solr from the command line. +*<>*: Once you have Solr configured, you want to deploy it to production and keep it up to date. This section includes information about how to take Solr to production, run it in HDFS or AWS, and information about upgrades and managing Solr from the command line. -*<>*: Solr includes options for keeping an eye on the performance of your Solr cluster with the web-based administration console, through the command line interface, or using REST APIs. +*<>*: Solr includes options for keeping an eye on the performance of your Solr cluster with the web-based administration console, through the command line interface, or using REST APIs. **** -- @@ -91,22 +91,22 @@ The *<>* section guides yo .Indexing Documents [sidebar.col] **** -*<>*: This section describes the indexing process and basic index operations, such as commit, optimize, and rollback. +*<>*: This section describes the indexing process and basic index operations, such as commit, optimize, and rollback. -*<>*: This section describes how Solr organizes data in the index. It explains how a Solr schema defines the fields and field types which Solr uses to organize data within the document files it indexes. +*<>*: This section describes how Solr organizes data in the index. It explains how a Solr schema defines the fields and field types which Solr uses to organize data within the document files it indexes. -*<>*: This section explains how Solr prepares text for indexing and searching. Analyzers parse text and produce a stream of tokens, lexical units used for indexing and searching. Tokenizers break field data down into tokens. Filters perform other transformational or selective work on token streams. +*<>*: This section explains how Solr prepares text for indexing and searching. Analyzers parse text and produce a stream of tokens, lexical units used for indexing and searching. Tokenizers break field data down into tokens. Filters perform other transformational or selective work on token streams. **** .Searching Documents [sidebar.col] **** -*<>*: This section presents an overview of the search process in Solr. It describes the main components used in searches, including request handlers, query parsers, and response writers. It lists the query parameters that can be passed to Solr, and it describes features such as boosting and faceting, which can be used to fine-tune search results. +*<>*: This section presents an overview of the search process in Solr. It describes the main components used in searches, including request handlers, query parsers, and response writers. It lists the query parameters that can be passed to Solr, and it describes features such as boosting and faceting, which can be used to fine-tune search results. -*<>*: A stream processing language for Solr, with a suite of functions to perform many types of queries and parallel execution tasks. +*<>*: A stream processing language for Solr, with a suite of functions to perform many types of queries and parallel execution tasks. -*<>*: This section tells you how to access Solr through various client APIs, including JavaScript, JSON, and Ruby. +*<>*: This section tells you how to access Solr through various client APIs, including JavaScript, JSON, and Ruby. **** -- @@ -120,20 +120,20 @@ The *<>* section guides yo .Scaling Solr [sidebar.col] **** -*<>*: This section describes SolrCloud, which provides comprehensive distributed capabilities. +*<>*: This section describes SolrCloud, which provides comprehensive distributed capabilities. -*<>*: This section tells you how to grow a Solr distribution by dividing a large index into sections called shards, which are then distributed across multiple servers, or by replicating a single index across multiple services. +*<>*: This section tells you how to grow a Solr distribution by dividing a large index into sections called shards, which are then distributed across multiple servers, or by replicating a single index across multiple services. -*<>*: This section talks about circuit breakers, a way of allowing a higher stability of Solr nodes and increased service level guarantees of requests that are accepted by Solr. +*<>*: This section talks about circuit breakers, a way of allowing a higher stability of Solr nodes and increased service level guarantees of requests that are accepted by Solr. -*<>*: This section talks about request rate limiters, a way of guaranteeing throughput per request type and dedicating resource quotas by resource type. Rate limiter configurations are per instance/JVM and applied to the entire JVM, not at a core/collection level. +*<>*: This section talks about request rate limiters, a way of guaranteeing throughput per request type and dedicating resource quotas by resource type. Rate limiter configurations are per instance/JVM and applied to the entire JVM, not at a core/collection level. **** .Advanced Configuration [sidebar.col] **** -*<>*: When planning how to secure Solr, you should consider which of the available features or approaches are right for you. +*<>*: When planning how to secure Solr, you should consider which of the available features or approaches are right for you. -*<>*: This section discusses performance tuning for Solr. It begins with an overview of the `solrconfig.xml` file, then tells you how to configure cores with `solr.xml`, how to configure the Lucene index writer, and more. +*<>*: This section discusses performance tuning for Solr. It begins with an overview of the `solrconfig.xml` file, then tells you how to configure cores with `solr.xml`, how to configure the Lucene index writer, and more. **** -- diff --git a/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc b/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc index b3dfd47cb12..490273ac5be 100644 --- a/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/indexconfig-in-solrconfig.adoc @@ -168,7 +168,7 @@ The defaults for the above attributes are dynamically set based on whether the u === mergedSegmentWarmer -When using Solr in for <> a merged segment warmer can be configured to warm the reader on the newly merged segment, before the merge commits. This is not required for near real-time search, but will reduce search latency on opening a new near real-time reader after a merge completes. +When using Solr in for <> a merged segment warmer can be configured to warm the reader on the newly merged segment, before the merge commits. This is not required for near real-time search, but will reduce search latency on opening a new near real-time reader after a merge completes. [source,xml] ---- @@ -198,14 +198,14 @@ Many <> implementations support `noCFSRatio The LockFactory options specify the locking implementation to use. -The set of valid lock type options depends on the <> you have configured. +The set of valid lock type options depends on the <> you have configured. The values listed below are are supported by `StandardDirectoryFactory` (the default): * `native` (default) uses NativeFSLockFactory to specify native OS file locking. If a second Solr process attempts to access the directory, it will fail. Do not use when multiple Solr web applications are attempting to share a single index. See also the {lucene-javadocs}/core/org/apache/lucene/store/NativeFSLockFactory.html[Javadocs]. * `simple` uses SimpleFSLockFactory to specify a plain file for locking. See also the {lucene-javadocs}/core/org/apache/lucene/store/SimpleFSLockFactory.html[Javadocs]. * `single` (expert) uses SingleInstanceLockFactory. Use for special situations of a read-only index directory, or when there is no possibility of more than one process trying to modify the index (even sequentially). This type will protect against multiple cores within the _same_ JVM attempting to access the same index. WARNING! If multiple Solr instances in different JVMs modify an index, this type will _not_ protect against index corruption. See also the {lucene-javadocs}/core/org/apache/lucene/store/SingleInstanceLockFactory.html[Javadocs]. -* `hdfs` uses HdfsLockFactory to support reading and writing index and transaction log files to a HDFS filesystem. See the section <> for more details on using this feature. +* `hdfs` uses HdfsLockFactory to support reading and writing index and transaction log files to a HDFS filesystem. See the section <> for more details on using this feature. [source,xml] ---- diff --git a/solr/solr-ref-guide/src/indexing-and-basic-data-operations.adoc b/solr/solr-ref-guide/src/indexing-and-basic-data-operations.adoc index 993a4a26e35..204a978337d 100644 --- a/solr/solr-ref-guide/src/indexing-and-basic-data-operations.adoc +++ b/solr/solr-ref-guide/src/indexing-and-basic-data-operations.adoc @@ -29,28 +29,28 @@ This section describes how Solr adds data to its index. It covers the following topics: -* *<>*: An overview of Solr's indexing process. +* *<>*: An overview of Solr's indexing process. -* *<>*: Information about using `post.jar` to quickly upload some content to your system. +* *<>*: Information about using `post.jar` to quickly upload some content to your system. -* *<>*: Information about using Solr's Index Handlers to upload XML/XSLT, JSON and CSV data. +* *<>*: Information about using Solr's Index Handlers to upload XML/XSLT, JSON and CSV data. -* *<>*: Index any JSON of your choice +* *<>*: Index any JSON of your choice -* *<>*: Detailed information about indexing and schema configuration for nested documents. +* *<>*: Detailed information about indexing and schema configuration for nested documents. -* *<>*: Information about using the Solr Cell framework to upload data for indexing. +* *<>*: Information about using the Solr Cell framework to upload data for indexing. -* *<>*: Information about how to use atomic updates and optimistic concurrency with Solr. +* *<>*: Information about how to use atomic updates and optimistic concurrency with Solr. -* *<>*: Information about using language identification during the indexing process. +* *<>*: Information about using language identification during the indexing process. -* *<>*: Information about configuring Solr to mark duplicate documents as they are indexed. +* *<>*: Information about configuring Solr to mark duplicate documents as they are indexed. -* *<>*: Information about streaming content to Solr Request Handlers. +* *<>*: Information about streaming content to Solr Request Handlers. -* *<>*: Details about when reindexing is required or recommended, and some strategies for completely reindexing your documents. +* *<>*: Details about when reindexing is required or recommended, and some strategies for completely reindexing your documents. == Indexing Using Client APIs -Using client APIs, such as <>, from your applications is an important option for updating Solr indexes. See the <> section for more information. +Using client APIs, such as <>, from your applications is an important option for updating Solr indexes. See the <> section for more information. diff --git a/solr/solr-ref-guide/src/indexing-nested-documents.adoc b/solr/solr-ref-guide/src/indexing-nested-documents.adoc index 4e815875023..084dc01b9f4 100644 --- a/solr/solr-ref-guide/src/indexing-nested-documents.adoc +++ b/solr/solr-ref-guide/src/indexing-nested-documents.adoc @@ -18,7 +18,7 @@ // specific language governing permissions and limitations // under the License. -Solr supports indexing nested documents, described here, and ways to <> them very efficiently. +Solr supports indexing nested documents, described here, and ways to <> them very efficiently. By way of examples: nested documents in Solr can be used to bind a blog post (parent document) with comments (child documents) -- or as a way to model major product lines as parent documents, @@ -33,7 +33,7 @@ In terms of performance, indexing the relationships between documents usually yi since the relationships are already stored in the index and do not need to be computed. However, nested documents are less flexible than query time joins as it imposes rules that some applications may not be able to accept. -Nested documents may be indexed via either the XML or JSON data syntax, and is also supported by <> with javabin. +Nested documents may be indexed via either the XML or JSON data syntax, and is also supported by <> with javabin. [CAUTION] diff --git a/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc b/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc index aa21f5f42e0..3bc4282af84 100644 --- a/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/initparams-in-solrconfig.adoc @@ -20,7 +20,7 @@ The `` section of `solrconfig.xml` allows you to define request hand There are a couple of use cases where this might be desired: -* Some handlers are implicitly defined in code - see <> - and there should be a way to add/append/override some of the implicitly defined properties. +* Some handlers are implicitly defined in code - see <> - and there should be a way to add/append/override some of the implicitly defined properties. * There are a few properties that are used across handlers. This helps you keep only a single definition of those properties and apply them over multiple handlers. For example, if you want several of your search handlers to return the same list of fields, you can create an `` section without having to define the same set of parameters in each request handler definition. If you have a single request handler that should return different fields, you can define the overriding parameters in individual `` sections as usual. diff --git a/solr/solr-ref-guide/src/installing-solr.adoc b/solr/solr-ref-guide/src/installing-solr.adoc index 962375e7984..6b861ea6838 100644 --- a/solr/solr-ref-guide/src/installing-solr.adoc +++ b/solr/solr-ref-guide/src/installing-solr.adoc @@ -19,7 +19,7 @@ Installation of Solr on Unix-compatible or Windows servers generally requires simply extracting (or, unzipping) the download package. -Please be sure to review the <> before starting Solr. +Please be sure to review the <> before starting Solr. == Available Solr Packages @@ -37,7 +37,7 @@ When getting started with Solr, all you need to do is extract the Solr distribut When you've progressed past initial evaluation of Solr, you'll want to take care to plan your implementation. You may need to reinstall Solr on another server or make a clustered SolrCloud environment. -When you're ready to setup Solr for a production environment, please refer to the instructions provided on the <> page. +When you're ready to setup Solr for a production environment, please refer to the instructions provided on the <> page. .What Size Server Do I Need? [NOTE] @@ -47,7 +47,7 @@ How to size your Solr installation is a complex question that relies on a number It's highly recommended that you spend a bit of time thinking about the factors that will impact hardware sizing for your Solr implementation. A very good blog post that discusses the issues to consider is https://lucidworks.com/2012/07/23/sizing-hardware-in-the-abstract-why-we-dont-have-a-definitive-answer/[Sizing Hardware in the Abstract: Why We Don't have a Definitive Answer]. ==== -One thing to note when planning your installation is that a hard limit exists in Lucene for the number of documents in a single index: approximately 2.14 billion documents (2,147,483,647 to be exact). In practice, it is highly unlikely that such a large number of documents would fit and perform well in a single index, and you will likely need to distribute your index across a cluster before you ever approach this number. If you know you will exceed this number of documents in total before you've even started indexing, it's best to plan your installation with <> as part of your design from the start. +One thing to note when planning your installation is that a hard limit exists in Lucene for the number of documents in a single index: approximately 2.14 billion documents (2,147,483,647 to be exact). In practice, it is highly unlikely that such a large number of documents would fit and perform well in a single index, and you will likely need to distribute your index across a cluster before you ever approach this number. If you know you will exceed this number of documents in total before you've even started indexing, it's best to plan your installation with <> as part of your design from the start. == Package Installation @@ -68,15 +68,15 @@ After installing Solr, you'll see the following directories and files within the bin/:: This directory includes several important scripts that will make using Solr easier. -solr and solr.cmd::: This is <>, also known as `bin/solr` (*nix) / `bin/solr.cmd` (Windows). This script is the preferred tool to start and stop Solr. You can also create collections or cores, configure authentication, and work with configuration files when running in SolrCloud mode. +solr and solr.cmd::: This is <>, also known as `bin/solr` (*nix) / `bin/solr.cmd` (Windows). This script is the preferred tool to start and stop Solr. You can also create collections or cores, configure authentication, and work with configuration files when running in SolrCloud mode. -post::: The <>, which provides a simple command line interface for POSTing content to Solr. +post::: The <>, which provides a simple command line interface for POSTing content to Solr. solr.in.sh and solr.in.cmd::: These are property files for *nix and Windows systems, respectively. System-level properties for Java, Jetty, and Solr are configured here. Many of these settings can be overridden when using `bin/solr` / `bin/solr.cmd`, but this allows you to set all the properties in one place. install_solr_services.sh::: -This script is used on *nix systems to install Solr as a service. It is described in more detail in the section <>. +This script is used on *nix systems to install Solr as a service. It is described in more detail in the section <>. contrib/:: Solr's `contrib` directory includes add-on plugins for specialized features of Solr. @@ -97,17 +97,17 @@ server/:: This directory is where the heart of the Solr application resides. A README in this directory provides a detailed overview, but here are some highlights: * Solr's Admin UI (`server/solr-webapp`) * Jetty libraries (`server/lib`) -* Log files (`server/logs`) and log configurations (`server/resources`). See the section <> for more details on how to customize Solr's default logging. +* Log files (`server/logs`) and log configurations (`server/resources`). See the section <> for more details on how to customize Solr's default logging. * Sample configsets (`server/solr/configsets`) == Solr Examples -Solr includes a number of example documents and configurations to use when getting started. If you ran through the <>, you have already interacted with some of these files. +Solr includes a number of example documents and configurations to use when getting started. If you ran through the <>, you have already interacted with some of these files. Here are the examples included with Solr: exampledocs:: -This is a small set of simple CSV, XML, and JSON files that can be used with `bin/post` when first getting started with Solr. For more information about using `bin/post` with these files, see <>. +This is a small set of simple CSV, XML, and JSON files that can be used with `bin/post` when first getting started with Solr. For more information about using `bin/post` with these files, see <>. files:: The `files` directory provides a basic search UI for documents such as Word or PDF that you may have stored locally. See the README there for details on how to use this example. @@ -137,7 +137,7 @@ This will start Solr in the background, listening on port 8983. When you start Solr in the background, the script will wait to make sure Solr starts correctly before returning to the command line prompt. -TIP: All of the options for the Solr CLI are described in the section <>. +TIP: All of the options for the Solr CLI are described in the section <>. === Start Solr with a Specific Bundled Example @@ -151,7 +151,7 @@ bin/solr -e techproducts Currently, the available examples you can run are: techproducts, schemaless, and cloud. See the section <> for details on each example. .Getting Started with SolrCloud -NOTE: Running the `cloud` example starts Solr in <> mode. For more information on starting Solr in SolrCloud mode, see the section <>. +NOTE: Running the `cloud` example starts Solr in <> mode. For more information on starting Solr in SolrCloud mode, see the section <>. === Check if Solr is Running diff --git a/solr/solr-ref-guide/src/introduction-to-client-apis.adoc b/solr/solr-ref-guide/src/introduction-to-client-apis.adoc index ae2640b3ec9..ecb59d6d7c4 100644 --- a/solr/solr-ref-guide/src/introduction-to-client-apis.adoc +++ b/solr/solr-ref-guide/src/introduction-to-client-apis.adoc @@ -26,4 +26,4 @@ Clients use Solr's five fundamental operations to work with Solr. The operations Queries are executed by creating a URL that contains all the query parameters. Solr examines the request URL, performs the query, and returns the results. The other operations are similar, although in certain cases the HTTP request is a POST operation and contains information beyond whatever is included in the request URL. An index operation, for example, may contain a document in the body of the request. -Solr also features an EmbeddedSolrServer that offers a Java API without requiring an HTTP connection. For details, see <>. +Solr also features an EmbeddedSolrServer that offers a Java API without requiring an HTTP connection. For details, see <>. diff --git a/solr/solr-ref-guide/src/introduction-to-scaling-and-distribution.adoc b/solr/solr-ref-guide/src/introduction-to-scaling-and-distribution.adoc index 2b0f769d1a7..19a1941b318 100644 --- a/solr/solr-ref-guide/src/introduction-to-scaling-and-distribution.adoc +++ b/solr/solr-ref-guide/src/introduction-to-scaling-and-distribution.adoc @@ -20,11 +20,11 @@ Both Lucene and Solr were designed to scale to support large implementations wit This section covers: -* <> an index across multiple servers -* <> an index on multiple servers -* <> +* <> an index across multiple servers +* <> an index on multiple servers +* <> -If you need full scale distribution of indexes and queries, as well as replication, load balancing and failover, you may want to use SolrCloud. Full details on configuring and using SolrCloud is available in the section <>. +If you need full scale distribution of indexes and queries, as well as replication, load balancing and failover, you may want to use SolrCloud. Full details on configuring and using SolrCloud is available in the section <>. == What Problem Does Distribution Solve? @@ -40,4 +40,4 @@ Replicating an index is useful when: * You have a large search volume which one machine cannot handle, so you need to distribute searches across multiple read-only copies of the index. * There is a high volume/high rate of indexing which consumes machine resources and reduces search performance on the indexing machine, so you need to separate indexing and searching. -* You want to make a backup of the index (see <>). +* You want to make a backup of the index (see <>). diff --git a/solr/solr-ref-guide/src/introduction-to-solr-indexing.adoc b/solr/solr-ref-guide/src/introduction-to-solr-indexing.adoc index ab09081ba13..52faff23d36 100644 --- a/solr/solr-ref-guide/src/introduction-to-solr-indexing.adoc +++ b/solr/solr-ref-guide/src/introduction-to-solr-indexing.adoc @@ -24,15 +24,15 @@ A Solr index can accept data from many different sources, including XML files, c Here are the three most common ways of loading data into a Solr index: -* Using the <> framework built on Apache Tika for ingesting binary files or structured files such as Office, Word, PDF, and other proprietary formats. +* Using the <> framework built on Apache Tika for ingesting binary files or structured files such as Office, Word, PDF, and other proprietary formats. * Uploading XML files by sending HTTP requests to the Solr server from any environment where such requests can be generated. -* Writing a custom Java application to ingest data through Solr's Java Client API (which is described in more detail in <>). Using the Java API may be the best choice if you're working with an application, such as a Content Management System (CMS), that offers a Java API. +* Writing a custom Java application to ingest data through Solr's Java Client API (which is described in more detail in <>). Using the Java API may be the best choice if you're working with an application, such as a Content Management System (CMS), that offers a Java API. Regardless of the method used to ingest data, there is a common basic data structure for data being fed into a Solr index: a _document_ containing multiple _fields,_ each with a _name_ and containing _content,_ which may be empty. One of the fields is usually designated as a unique ID field (analogous to a primary key in a database), although the use of a unique ID field is not strictly required by Solr. -If the field name is defined in the Schema that is associated with the index, then the analysis steps associated with that field will be applied to its content when the content is tokenized. Fields that are not explicitly defined in the Schema will either be ignored or mapped to a dynamic field definition (see <>), if one matching the field name exists. +If the field name is defined in the Schema that is associated with the index, then the analysis steps associated with that field will be applied to its content when the content is tokenized. Fields that are not explicitly defined in the Schema will either be ignored or mapped to a dynamic field definition (see <>), if one matching the field name exists. == The Solr Example Directory diff --git a/solr/solr-ref-guide/src/json-facet-api.adoc b/solr/solr-ref-guide/src/json-facet-api.adoc index e1e21c4edc6..519dd214d13 100644 --- a/solr/solr-ref-guide/src/json-facet-api.adoc +++ b/solr/solr-ref-guide/src/json-facet-api.adoc @@ -581,7 +581,7 @@ Unlike all the facets discussed so far, Aggregation functions (also called *face |relatedness |`relatedness('popularity:[100 TO *]','inStock:true')`|A function for computing a relatedness score of the documents in the domain to a Foreground set, relative to a Background set (both defined as queries). This is primarily for use when building <>. |=== -Numeric aggregation functions such as `avg` can be on any numeric field, or on a <> of multiple numeric fields such as `avg(div(popularity,price))`. +Numeric aggregation functions such as `avg` can be on any numeric field, or on a <> of multiple numeric fields such as `avg(div(popularity,price))`. The most common way of requesting an aggregation function is as a simple String containing the expression you wish to compute: @@ -617,7 +617,7 @@ include::{example-source-dir}JsonRequestApiTest.java[tag=solrj-json-metrics-face ==== -- -An expanded form allows for <> to be specified. These may be used explicitly by some specialized aggregations such as `<>`, but can also be used as parameter references to make aggregation expressions more readable, with out needing to use (global) request parameters: +An expanded form allows for <> to be specified. These may be used explicitly by some specialized aggregations such as `<>`, but can also be used as parameter references to make aggregation expressions more readable, with out needing to use (global) request parameters: [.dynamic-tabs] -- @@ -834,7 +834,7 @@ As discussed above, facets compute buckets or statistics based on their "domain" * By default, top-level facets use the set of all documents matching the main query as their domain. * Nested "sub-facets" are computed for every bucket of their parent facet, using a domain containing all documents in that bucket. -In addition to this default behavior, domains can be also be widened, narrowed, or changed entirely. The JSON Faceting API supports modifying domains through its `domain` property. This is discussed in more detail <> +In addition to this default behavior, domains can be also be widened, narrowed, or changed entirely. The JSON Faceting API supports modifying domains through its `domain` property. This is discussed in more detail <> == Special Stat Facet Functions @@ -842,7 +842,7 @@ Most stat facet functions (`avg`, `sumsq`, etc.) allow users to perform math com === uniqueBlock() and Block Join Counts -When a collection contains <>, the `blockChildren` and `blockParent` <> can be useful when searching for parent documents and you want to compute stats against all of the affected children documents (or vice versa). +When a collection contains <>, the `blockChildren` and `blockParent` <> can be useful when searching for parent documents and you want to compute stats against all of the affected children documents (or vice versa). But if you only need to know the _count_ of all the blocks that exist in the current domain, a more efficient option is the `uniqueBlock()` aggregate function. Suppose we have products with multiple SKUs, and we want to count products for each color. diff --git a/solr/solr-ref-guide/src/json-faceting-domain-changes.adoc b/solr/solr-ref-guide/src/json-faceting-domain-changes.adoc index 4e3014b10fb..95b2fa3d8af 100644 --- a/solr/solr-ref-guide/src/json-faceting-domain-changes.adoc +++ b/solr/solr-ref-guide/src/json-faceting-domain-changes.adoc @@ -214,7 +214,7 @@ NOTE: While a `query` domain can be combined with an additional domain `filter`, == Block Join Domain Changes -When a collection contains <>, the `blockChildren` or `blockParent` domain options can be used to transform an existing domain containing one type of document, into a domain containing the documents with the specified relationship (child or parent of) to the documents from the original domain. +When a collection contains <>, the `blockChildren` or `blockParent` domain options can be used to transform an existing domain containing one type of document, into a domain containing the documents with the specified relationship (child or parent of) to the documents from the original domain. Both of these options work similarly to the corresponding <> by taking in a single String query that exclusively matches all parent documents in the collection. If `blockParent` is used, then the resulting domain will contain all parent documents of the children from the original domain. If `blockChildren` is used, then the resulting domain will contain all child documents of the parents from the original domain. Quite often facets over child documents needs to be counted in parent documents, this can be done by `uniqueBlock(\_root_)` as described in <>. diff --git a/solr/solr-ref-guide/src/json-query-dsl.adoc b/solr/solr-ref-guide/src/json-query-dsl.adoc index a02de28c856..28eb02d0655 100644 --- a/solr/solr-ref-guide/src/json-query-dsl.adoc +++ b/solr/solr-ref-guide/src/json-query-dsl.adoc @@ -23,9 +23,9 @@ Queries and filters provided in JSON requests can be specified using a rich, pow == Query DSL Structure The JSON Request API accepts query values in three different formats: -* A valid <> that uses the default `deftype` (`lucene`, in most cases). e.g., `title:solr`. +* A valid <> that uses the default `deftype` (`lucene`, in most cases). e.g., `title:solr`. -* A valid <> that specifies its `deftype` explicitly. e.g., `{!dismax qf=title}solr`. +* A valid <> that specifies its `deftype` explicitly. e.g., `{!dismax qf=title}solr`. * A valid JSON object with the name of the query parser and any relevant parameters. e.g., `{ "lucene": {"df":"title", "query":"solr"}}`. ** The top level "query" JSON block generally only has a single property representing the name of the query parser to use. The value for the query parser property is a child block containing any relevant parameters as JSON properties. The whole structure is analogous to a "local-params" query string. The query itself (often represented in local params using the name `v`) is specified with the key `query` instead. diff --git a/solr/solr-ref-guide/src/kerberos-authentication-plugin.adoc b/solr/solr-ref-guide/src/kerberos-authentication-plugin.adoc index af10d214d28..428898b2a3c 100644 --- a/solr/solr-ref-guide/src/kerberos-authentication-plugin.adoc +++ b/solr/solr-ref-guide/src/kerberos-authentication-plugin.adoc @@ -18,13 +18,13 @@ If you are using Kerberos to secure your network environment, the Kerberos authentication plugin can be used to secure a Solr cluster. -This allows Solr to use a Kerberos service principal and keytab file to authenticate with ZooKeeper and between nodes of the Solr cluster (if applicable). Users of the Admin UI and all clients (such as <>) would also need to have a valid ticket before being able to use the UI or send requests to Solr. +This allows Solr to use a Kerberos service principal and keytab file to authenticate with ZooKeeper and between nodes of the Solr cluster (if applicable). Users of the Admin UI and all clients (such as <>) would also need to have a valid ticket before being able to use the UI or send requests to Solr. Support for the Kerberos authentication plugin is available in SolrCloud mode or standalone mode. [TIP] ==== -If you are using Solr with a Hadoop cluster secured with Kerberos and intend to store your Solr indexes in HDFS, also see the section <> for additional steps to configure Solr for that purpose. The instructions on this page apply only to scenarios where Solr will be secured with Kerberos. If you only need to store your indexes in a Kerberized HDFS system, please see the other section referenced above. +If you are using Solr with a Hadoop cluster secured with Kerberos and intend to store your Solr indexes in HDFS, also see the section <> for additional steps to configure Solr for that purpose. The instructions on this page apply only to scenarios where Solr will be secured with Kerberos. If you only need to store your indexes in a Kerberized HDFS system, please see the other section referenced above. ==== == How Solr Works With Kerberos @@ -33,7 +33,7 @@ When setting up Solr to use Kerberos, configurations are put in place for Solr t === security.json -The Solr authentication model uses a file called `security.json`. A description of this file and how it is created and maintained is covered in the section <>. If this file is created after an initial startup of Solr, a restart of each node of the system is required. +The Solr authentication model uses a file called `security.json`. A description of this file and how it is created and maintained is covered in the section <>. If this file is created after an initial startup of Solr, a restart of each node of the system is required. === Service Principals and Keytab Files @@ -176,11 +176,11 @@ server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd put /security. If you are using Solr in standalone mode, you need to create the `security.json` file and put it in your `$SOLR_HOME` directory. -More details on how to use a `/security.json` file in Solr are available in the section <>. +More details on how to use a `/security.json` file in Solr are available in the section <>. [IMPORTANT] ==== -If you already have a `/security.json` file in ZooKeeper, download the file, add or modify the authentication section and upload it back to ZooKeeper using the <> available in Solr. +If you already have a `/security.json` file in ZooKeeper, download the file, add or modify the authentication section and upload it back to ZooKeeper using the <> available in Solr. ==== === Define a JAAS Configuration File @@ -217,7 +217,7 @@ The main properties we are concerned with are the `keyTab` and `principal` prope === Solr Startup Parameters -While starting up Solr, the following host-specific parameters need to be passed. These parameters can be passed at the command line with the `bin/solr` start command (see <> for details on how to pass system parameters) or defined in `bin/solr.in.sh` or `bin/solr.in.cmd` as appropriate for your operating system. +While starting up Solr, the following host-specific parameters need to be passed. These parameters can be passed at the command line with the `bin/solr` start command (see <> for details on how to pass system parameters) or defined in `bin/solr.in.sh` or `bin/solr.in.cmd` as appropriate for your operating system. `solr.kerberos.name.rules`:: Used to map Kerberos principals to short names. Default value is `DEFAULT`. Example of a name rule: `RULE:[1:$1@$0](.\*EXAMPLE.COM)s/@.*//`. @@ -269,7 +269,7 @@ There are a few use cases for Solr where this might be helpful: * When load on the Kerberos server is high. Delegation tokens can reduce the load because they do not access the server after the first request. * If requests or permissions need to be delegated to another user. -To enable delegation tokens, several parameters must be defined. These parameters can be passed at the command line with the `bin/solr` start command (see <> for details on how to pass system parameters) or defined in `bin/solr.in.sh` or `bin/solr.in.cmd` as appropriate for your operating system. +To enable delegation tokens, several parameters must be defined. These parameters can be passed at the command line with the `bin/solr` start command (see <> for details on how to pass system parameters) or defined in `bin/solr.in.sh` or `bin/solr.in.cmd` as appropriate for your operating system. `solr.kerberos.delegation.token.enabled`:: This is `false` by default, set to `true` to enable delegation tokens. This parameter is required if you want to enable tokens. diff --git a/solr/solr-ref-guide/src/language-analysis.adoc b/solr/solr-ref-guide/src/language-analysis.adoc index afdd91dccbb..fcf60a25e59 100644 --- a/solr/solr-ref-guide/src/language-analysis.adoc +++ b/solr/solr-ref-guide/src/language-analysis.adoc @@ -23,13 +23,13 @@ For the European languages, tokenization is fairly straightforward. Tokens are d In other languages the tokenization rules are often not so simple. Some European languages may also require special tokenization rules, such as rules for decompounding German words. -For information about language detection at index time, see <>. +For information about language detection at index time, see <>. == KeywordMarkerFilterFactory Protects words from being modified by stemmers. A customized protected word list may be specified with the "protected" attribute in the schema. Any words in the protected word list will not be modified by any stemmer in Solr. -A sample Solr `protwords.txt` with comments can be found in the `sample_techproducts_configs` <> directory: +A sample Solr `protwords.txt` with comments can be found in the `sample_techproducts_configs` <> directory: [.dynamic-tabs] -- @@ -166,7 +166,7 @@ Compound words are most commonly found in Germanic languages. *Arguments:* -`dictionary`:: (required) The path of a file that contains a list of simple words, one per line. Blank lines and lines that begin with "#" are ignored. See <> for more information. +`dictionary`:: (required) The path of a file that contains a list of simple words, one per line. Blank lines and lines that begin with "`#`" are ignored. See <> for more information. `minWordSize`:: (integer, default 5) Any token shorter than this is not decompounded. @@ -497,9 +497,9 @@ The OpenNLP Tokenizer takes two language-specific binary model files as paramete *Arguments:* -`sentenceModel`:: (required) The path of a language-specific OpenNLP sentence detection model file. See <> for more information. +`sentenceModel`:: (required) The path of a language-specific OpenNLP sentence detection model file. See <> for more information. -`tokenizerModel`:: (required) The path of a language-specific OpenNLP tokenization model file. See <> for more information. +`tokenizerModel`:: (required) The path of a language-specific OpenNLP tokenization model file. See <> for more information. *Example:* @@ -541,7 +541,7 @@ NOTE: Lucene currently does not index token types, so if you want to keep this i *Arguments:* -`posTaggerModel`:: (required) The path of a language-specific OpenNLP POS tagger model file. See <> for more information. +`posTaggerModel`:: (required) The path of a language-specific OpenNLP POS tagger model file. See <> for more information. *Examples:* @@ -636,7 +636,7 @@ NOTE: Lucene currently does not index token types, so if you want to keep this i *Arguments:* -`chunkerModel`:: (required) The path of a language-specific OpenNLP phrase chunker model file. See <> for more information. +`chunkerModel`:: (required) The path of a language-specific OpenNLP phrase chunker model file. See <> for more information. *Examples*: @@ -700,9 +700,9 @@ This filter replaces the text of each token with its lemma. Both a dictionary-ba Either `dictionary` or `lemmatizerModel` must be provided, and both may be provided - see the examples below: -`dictionary`:: (optional) The path of a lemmatization dictionary file. See <> for more information. The dictionary file must be encoded as UTF-8, with one entry per line, in the form `word[tab]lemma[tab]part-of-speech`, e.g., `wrote[tab]write[tab]VBD`. +`dictionary`:: (optional) The path of a lemmatization dictionary file. See <> for more information. The dictionary file must be encoded as UTF-8, with one entry per line, in the form `word[tab]lemma[tab]part-of-speech`, e.g., `wrote[tab]write[tab]VBD`. -`lemmatizerModel`:: (optional) The path of a language-specific OpenNLP lemmatizer model file. See <> for more information. +`lemmatizerModel`:: (optional) The path of a language-specific OpenNLP lemmatizer model file. See <> for more information. *Examples:* @@ -1887,7 +1887,7 @@ Removes terms with one of the configured parts-of-speech. `JapaneseTokenizer` an *Arguments:* -`tags`:: filename for a list of parts-of-speech for which to remove terms; see `conf/lang/stoptags_ja.txt` in the `sample_techproducts_config` <> for an example. +`tags`:: filename for a list of parts-of-speech for which to remove terms; see `conf/lang/stoptags_ja.txt` in the `sample_techproducts_config` <> for an example. `enablePositionIncrements`:: if `luceneMatchVersion` is `4.3` or earlier and `enablePositionIncrements="false"`, no position holes will be left by this filter when it removes tokens. *This argument is invalid if `luceneMatchVersion` is `5.0` or later.* diff --git a/solr/solr-ref-guide/src/learning-to-rank.adoc b/solr/solr-ref-guide/src/learning-to-rank.adoc index 62a8d5fecd6..27819164b7b 100644 --- a/solr/solr-ref-guide/src/learning-to-rank.adoc +++ b/solr/solr-ref-guide/src/learning-to-rank.adoc @@ -24,7 +24,7 @@ The module also supports feature extraction inside Solr. The only thing you need === Re-Ranking -Re-Ranking allows you to run a simple query for matching documents and then re-rank the top N documents using the scores from a different, more complex query. This page describes the use of *LTR* complex queries, information on other rank queries included in the Solr distribution can be found on the <> page. +Re-Ranking allows you to run a simple query for matching documents and then re-rank the top N documents using the scores from a different, more complex query. This page describes the use of *LTR* complex queries, information on other rank queries included in the Solr distribution can be found on the <> page. === Learning To Rank Models @@ -83,7 +83,7 @@ The LTR contrib module includes several feature classes as well as support for c ==== Feature Extraction -The ltr contrib module includes a <> transformer] to support the calculation and return of feature values for https://en.wikipedia.org/wiki/Feature_extraction[feature extraction] purposes including and especially when you do not yet have an actual reranking model. +The ltr contrib module includes a <> transformer] to support the calculation and return of feature values for https://en.wikipedia.org/wiki/Feature_extraction[feature extraction] purposes including and especially when you do not yet have an actual reranking model. ==== Feature Selection and Model Training @@ -662,7 +662,7 @@ As an alternative to the above-described `DefaultWrapperModel`, it is possible t === Applying Changes -The feature store and the model store are both <>. Changes made to managed resources are not applied to the active Solr components until the Solr collection (or Solr core in single server mode) is reloaded. +The feature store and the model store are both <>. Changes made to managed resources are not applied to the active Solr components until the Solr collection (or Solr core in single server mode) is reloaded. === LTR Examples diff --git a/solr/solr-ref-guide/src/legacy-scaling-and-distribution.adoc b/solr/solr-ref-guide/src/legacy-scaling-and-distribution.adoc index fa8cc1e04f2..4596935c2d7 100644 --- a/solr/solr-ref-guide/src/legacy-scaling-and-distribution.adoc +++ b/solr/solr-ref-guide/src/legacy-scaling-and-distribution.adoc @@ -21,12 +21,12 @@ This section describes how to set up distribution and replication in Solr. It is This section covers the following topics: -<>: Conceptual information about distribution and replication in Solr. +<>: Conceptual information about distribution and replication in Solr. -<>: Detailed information about implementing distributed searching in Solr. +<>: Detailed information about implementing distributed searching in Solr. -<>: Detailed information about replicating your Solr indexes. +<>: Detailed information about replicating your Solr indexes. -<>: Detailed information about replicating shards in a distributed index. +<>: Detailed information about replicating shards in a distributed index. -<>: Information about combining separate indexes in Solr. +<>: Information about combining separate indexes in Solr. diff --git a/solr/solr-ref-guide/src/libs.adoc b/solr/solr-ref-guide/src/libs.adoc index 07de240f67a..ebc40218944 100644 --- a/solr/solr-ref-guide/src/libs.adoc +++ b/solr/solr-ref-guide/src/libs.adoc @@ -45,7 +45,7 @@ Solr plugins won't work in these locations. == Lib Directives in SolrConfig -_Both_ plugin and <> file paths are configurable via `` directives in `solrconfig.xml`. +_Both_ plugin and <> file paths are configurable via `` directives in `solrconfig.xml`. When a directive matches a directory, then resources can be resolved from it. When a directive matches a `.jar` file, Solr plugins and their dependencies are resolved from it. Resources can be placed in a `.jar` too but that's unusual. diff --git a/solr/solr-ref-guide/src/local-parameters-in-queries.adoc b/solr/solr-ref-guide/src/local-parameters-in-queries.adoc index d6bdaff759a..d7d29b7c078 100644 --- a/solr/solr-ref-guide/src/local-parameters-in-queries.adoc +++ b/solr/solr-ref-guide/src/local-parameters-in-queries.adoc @@ -52,7 +52,7 @@ is equivalent to: `q={!type=dismax qf=myfield}solr rocks` -If no "type" is specified (either explicitly or implicitly) then the <> is used by default. Thus +If no "type" is specified (either explicitly or implicitly) then the <> is used by default. Thus `fq={!df=summary}solr rocks` diff --git a/solr/solr-ref-guide/src/logging.adoc b/solr/solr-ref-guide/src/logging.adoc index f514c05d3e5..5d2f023f8de 100644 --- a/solr/solr-ref-guide/src/logging.adoc +++ b/solr/solr-ref-guide/src/logging.adoc @@ -32,4 +32,4 @@ When you select the *Level* link on the left, you see the hierarchy of classpath .Log level selection image::images/logging/level_menu.png[image,width=589,height=250] -For an explanation of the various logging levels, see <>. +For an explanation of the various logging levels, see <>. diff --git a/solr/solr-ref-guide/src/logs.adoc b/solr/solr-ref-guide/src/logs.adoc index 489b542711b..e8dfc34647e 100644 --- a/solr/solr-ref-guide/src/logs.adoc +++ b/solr/solr-ref-guide/src/logs.adoc @@ -18,8 +18,8 @@ This section of the user guide provides an introduction to Solr log analytics. -NOTE: This is an appendix of the <>. All the functions described below are covered in detail in the guide. -See the <> chapter to learn how to get started with visualizations and Apache Zeppelin. +NOTE: This is an appendix of the <>. All the functions described below are covered in detail in the guide. +See the <> chapter to learn how to get started with visualizations and Apache Zeppelin. == Loading diff --git a/solr/solr-ref-guide/src/machine-learning.adoc b/solr/solr-ref-guide/src/machine-learning.adoc index 1c9bc8882aa..6ddb56cd139 100644 --- a/solr/solr-ref-guide/src/machine-learning.adoc +++ b/solr/solr-ref-guide/src/machine-learning.adoc @@ -463,7 +463,7 @@ each cluster. In this example the key features of the centroids are extracted to represent the key phrases for clusters of TF-IDF term vectors. NOTE: The example below works with TF-IDF _term vectors_. -The section <> offers +The section <> offers a full explanation of this features. In the example the `search` function returns documents where the `review_t` field matches the phrase "star wars". diff --git a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc index 184255bad1b..61d5f404fa9 100644 --- a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc +++ b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc @@ -18,7 +18,7 @@ There are some major changes in Solr 6 to consider before starting to migrate your configurations and indexes. -There are many hundreds of changes, so a thorough review of the <> section as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 6. This section attempts to highlight some of the major changes you should be aware of. +There are many hundreds of changes, so a thorough review of the <> section as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 6. This section attempts to highlight some of the major changes you should be aware of. == Highlights of New Features in Solr 6 @@ -27,7 +27,7 @@ Some of the major improvements in Solr 6 include: [[major-5-6-streaming]] === Streaming Expressions -Introduced in Solr 5, <> allow querying Solr and getting results as a stream of data, sorted and aggregated as requested. +Introduced in Solr 5, <> allow querying Solr and getting results as a stream of data, sorted and aggregated as requested. Several new expression types have been added in Solr 6: @@ -40,7 +40,7 @@ Several new expression types have been added in Solr 6: [[major-5-6-parallel-sql]] === Parallel SQL Interface -Built on streaming expressions, new in Solr 6 is a <> to be able to send SQL queries to Solr. SQL statements are compiled to streaming expressions on the fly, providing the full range of aggregations available to streaming expression requests. A JDBC driver is included, which allows using SQL clients and database visualization tools to query your Solr index and import data to other systems. +Built on streaming expressions, new in Solr 6 is a <> to be able to send SQL queries to Solr. SQL statements are compiled to streaming expressions on the fly, providing the full range of aggregations available to streaming expression requests. A JDBC driver is included, which allows using SQL clients and database visualization tools to query your Solr index and import data to other systems. === Cross Data Center Replication @@ -53,11 +53,11 @@ A new <> makes it po [[major-5-6-docvalues]] === DocValues -Most non-text field types in the Solr sample configsets now default to using <>. +Most non-text field types in the Solr sample configsets now default to using <>. == Java 8 Required -The minimum supported version of Java for Solr 6 (and the <>) is now Java 8. +The minimum supported version of Java for Solr 6 (and the <>) is now Java 8. == Index Format Changes @@ -65,25 +65,25 @@ Solr 6 has no support for reading Lucene/Solr 4.x and earlier indexes. Be sure t == Managed Schema is now the Default -Solr's default behavior when a `solrconfig.xml` does not explicitly define a `` is now dependent on the `luceneMatchVersion` specified in that `solrconfig.xml`. When `luceneMatchVersion < 6.0`, `ClassicIndexSchemaFactory` will continue to be used for back compatibility, otherwise an instance of <> will be used. +Solr's default behavior when a `solrconfig.xml` does not explicitly define a `` is now dependent on the `luceneMatchVersion` specified in that `solrconfig.xml`. When `luceneMatchVersion < 6.0`, `ClassicIndexSchemaFactory` will continue to be used for back compatibility, otherwise an instance of <> will be used. The most notable impacts of this change are: * Existing `solrconfig.xml` files that are modified to use `luceneMatchVersion >= 6.0`, but do _not_ have an explicitly configured `ClassicIndexSchemaFactory`, will have their `schema.xml` file automatically upgraded to a `managed-schema` file. -* Schema modifications via the <> will now be enabled by default. +* Schema modifications via the <> will now be enabled by default. -Please review the <> section for more details. +Please review the <> section for more details. == Default Similarity Changes -Solr's default behavior when a Schema does not explicitly define a global <`>> 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, without needing to also explicitly declare a global usage of `SchemaSimilarityFactory`. +Solr's default behavior when a Schema does not explicitly define a global <`>> 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, without needing to also explicitly declare a global usage of `SchemaSimilarityFactory`. 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 `` 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 -DELETESHARD and DELETEREPLICA now default to deleting the instance directory, data directory, and index directory for any replica they delete. Please review the <> documentation for details on new request parameters to prevent this behavior if you wish to keep all data on disk when using these commands. +DELETESHARD and DELETEREPLICA now default to deleting the instance directory, data directory, and index directory for any replica they delete. Please review the <> documentation for details on new request parameters to prevent this behavior if you wish to keep all data on disk when using these commands. == facet.date.* Parameters Removed -The `facet.date` parameter (and associated `facet.date.*` parameters) that were deprecated in Solr 3.x have been removed completely. If you have not yet switched to using the equivalent <> functionality you must do so now before upgrading. +The `facet.date` parameter (and associated `facet.date.*` parameters) that were deprecated in Solr 3.x have been removed completely. If you have not yet switched to using the equivalent <> functionality you must do so now before upgrading. diff --git a/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc b/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc index 2b9b0865bbe..ff6968d2756 100644 --- a/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc +++ b/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc @@ -21,15 +21,15 @@ Solr 7 is a major new release of Solr which introduces new features and a number == Upgrade Planning There are major changes in Solr 7 to consider before starting to migrate your configurations and indexes. This page is designed to highlight the biggest changes - new features you may want to be aware of, but also changes in default behavior and deprecated features that have been removed. -There are many hundreds of changes in Solr 7, however, so a thorough review of the <> as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 7. This section attempts to highlight some of the major changes you should be aware of. +There are many hundreds of changes in Solr 7, however, so a thorough review of the <> as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 7. This section attempts to highlight some of the major changes you should be aware of. You should also consider all changes that have been made to Solr in any version you have not upgraded to already. For example, if you are currently using Solr 6.2, you should review changes made in all subsequent 6.x releases in addition to changes for 7.0. <> your data is considered the best practice and you should try to do so if possible. However, if reindexing is not feasible, keep in mind you can only upgrade one major version at a time. Thus, Solr 6.x indexes will be compatible with Solr 7 but Solr 5.x indexes will not be. -If you do not reindex now, keep in mind that you will need to either reindex your data or upgrade your indexes before you will be able to move to Solr 8 when it is released in the future. See the section <> for more details on how to upgrade your indexes. +If you do not reindex now, keep in mind that you will need to either reindex your data or upgrade your indexes before you will be able to move to Solr 8 when it is released in the future. See the section <> for more details on how to upgrade your indexes. -See also the section <> for details on how to upgrade a SolrCloud cluster. +See also the section <> for details on how to upgrade a SolrCloud cluster. == New Features & Enhancements @@ -54,13 +54,13 @@ At its core, Solr autoscaling provides users with a rule syntax to define prefer ** The documentation for this component is in progress; until it is available, please refer to https://issues.apache.org/jira/browse/SOLR-11144[SOLR-11144] for more details. * There were several other new features released in earlier 6.x releases, which you may have missed: -** <> +** <> ** <> -** <>. See also information about related deprecations in the section <> below. +** <>. See also information about related deprecations in the section <> below. ** <> -** <> -** <> -** <> +** <> +** <> +** <> == Configuration and Default Changes @@ -79,7 +79,7 @@ To improve the functionality of Schemaless Mode, Solr now behaves differently wh * Incoming fields will be indexed as `text_general` by default (you can change this). The name of the field will be the same as the field name defined in the document. * A copy field rule will be inserted into your schema to copy the new `text_general` field to a new field with the name `_str`. This field's type will be a `strings` field (to allow for multiple values). The first 256 characters of the text field will be inserted to the new `strings` field. -This behavior can be customized if you wish to remove the copy field rule, or to change the number of characters inserted to the string field, or the field type used. See the section <> for details. +This behavior can be customized if you wish to remove the copy field rule, or to change the number of characters inserted to the string field, or the field type used. See the section <> for details. TIP: Because copy field rules can slow indexing and increase index size, it's recommended you only use copy fields when you need to. If you do not need to sort or facet on a field, you should remove the automatically-generated copy field rule. @@ -145,7 +145,7 @@ Choose one of these field types instead: * `SpatialRecursivePrefixTreeField` * `RptWithGeometrySpatialField` -See the section <> for more information. +See the section <> for more information. === JMX Support and MBeans * The `` element in `solrconfig.xml` has been removed in favor of `` elements defined in `solr.xml`. @@ -172,7 +172,7 @@ The following changes were made in SolrJ. * The `defaultSearchField` parameter in the schema is no longer supported. Use the `df` parameter instead. This option had been deprecated for several releases. See the section <> for more information. * The `mergePolicy`, `mergeFactor` and `maxMergeDocs` parameters have been removed and are no longer supported. You should define a `mergePolicyFactory` instead. See the section <> for more information. * The PostingsSolrHighlighter has been deprecated. It's recommended that you move to using the UnifiedHighlighter instead. See the section <> for more information about this highlighter. -* Index-time boosts have been removed from Lucene, and are no longer available from Solr. If any boosts are provided, they will be ignored by the indexing chain. As a replacement, index-time scoring factors should be indexed in a separate field and combined with the query score using a function query. See the section <> for more information. +* Index-time boosts have been removed from Lucene, and are no longer available from Solr. If any boosts are provided, they will be ignored by the indexing chain. As a replacement, index-time scoring factors should be indexed in a separate field and combined with the query score using a function query. See the section <> for more information. * The `StandardRequestHandler` is deprecated. Use `SearchHandler` instead. * To improve parameter consistency in the Collections API, the parameter names `fromNode` for the MOVEREPLICA command and `source`, `target` for the REPLACENODE command have been deprecated and replaced with `sourceNode` and `targetNode` instead. The old names will continue to work for back-compatibility but they will be removed in Solr 8. * The unused `valType` option has been removed from ExternalFileField, if you have this in your schema you can safely remove it. @@ -188,7 +188,7 @@ Note again that this is not a complete list of all changes that may impact your * If you use the JSON Facet API (json.facet) with `method=stream`, you must now set `sort='index asc'` to get the streaming behavior; otherwise it won't stream. Reminder: `method` is a hint that doesn't change defaults of other parameters. * If you use the JSON Facet API (json.facet) to facet on a numeric field and if you use `mincount=0` or if you set the prefix, you will now get an error as these options are incompatible with numeric faceting. * Solr's logging verbosity at the INFO level has been greatly reduced, and you may need to update the log configs to use the DEBUG level to see all the logging messages you used to see at INFO level before. -* We are no longer backing up `solr.log` and `solr_gc.log` files in date-stamped copies forever. If you relied on the `solr_log_` or `solr_gc_log_` being in the logs folder that will no longer be the case. See the section <> for details on how log rotation works as of Solr 6.3. +* We are no longer backing up `solr.log` and `solr_gc.log` files in date-stamped copies forever. If you relied on the `solr_log_` or `solr_gc_log_` being in the logs folder that will no longer be the case. See the section <> for details on how log rotation works as of Solr 6.3. * The create/deleteCollection methods on `MiniSolrCloudCluster` have been deprecated. Clients should instead use the `CollectionAdminRequest` API. In addition, `MiniSolrCloudCluster#uploadConfigDir(File, String)` has been deprecated in favour of `#uploadConfigSet(Path, String)`. * The `bin/solr.in.sh` (`bin/solr.in.cmd` on Windows) is now completely commented by default. Previously, this wasn't so, which had the effect of masking existing environment variables. * The `\_version_` field is no longer indexed and is now defined with `indexed=false` by default, because the field has DocValues enabled. @@ -198,7 +198,7 @@ Note again that this is not a complete list of all changes that may impact your ** The metrics "75thPctlRequestTime", "95thPctlRequestTime", "99thPctlRequestTime" and "999thPctlRequestTime" in Overseer Status API have been renamed to "75thPcRequestTime", "95thPcRequestTime" and so on for consistency with stats output in other parts of Solr. ** The metrics "avgRequestsPerMinute", "5minRateRequestsPerMinute" and "15minRateRequestsPerMinute" have been replaced by corresponding per-second rates viz. "avgRequestsPerSecond", "5minRateRequestsPerSecond" and "15minRateRequestsPerSecond" for consistency with stats output in other parts of Solr. * A new highlighter named UnifiedHighlighter has been added. You are encouraged to try out the UnifiedHighlighter by setting `hl.method=unified` and report feedback. It's more efficient/faster than the other highlighters, especially compared to the original Highlighter. See `HighlightParams.java` for a listing of highlight parameters annotated with which highlighters use them. `hl.useFastVectorHighlighter` is now considered deprecated in lieu of `hl.method=fastVector`. -* The <> now defaults to 1, and more importantly commits will now block if this limit is exceeded instead of throwing an exception (a good thing). Consequently there is no longer a risk in overlapping commits. Nonetheless users should continue to avoid excessive committing. Users are advised to remove any pre-existing `maxWarmingSearchers` entries from their `solrconfig.xml` files. +* The <> now defaults to 1, and more importantly commits will now block if this limit is exceeded instead of throwing an exception (a good thing). Consequently there is no longer a risk in overlapping commits. Nonetheless users should continue to avoid excessive committing. Users are advised to remove any pre-existing `maxWarmingSearchers` entries from their `solrconfig.xml` files. * The <> now supports leading wildcards. Beware of its possible heaviness, users are encouraged to use ReversedWildcardFilter in index time analysis. * The JMX metric "avgTimePerRequest" (and the corresponding metric in the metrics API for each handler) used to be a simple non-decaying average based on total cumulative time and the number of requests. The Codahale Metrics implementation applies exponential decay to this value, which heavily biases the average towards the last 5 minutes. -* Parallel SQL now uses Apache Calcite as its SQL framework. As part of this change the default aggregation mode has been changed to `facet` rather than `map_reduce`. There have also been changes to the SQL aggregate response and some SQL syntax changes. Consult the <> documentation for full details. +* Parallel SQL now uses Apache Calcite as its SQL framework. As part of this change the default aggregation mode has been changed to `facet` rather than `map_reduce`. There have also been changes to the SQL aggregate response and some SQL syntax changes. Consult the <> documentation for full details. diff --git a/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc b/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc index 2ed72aecfa7..eddd9f0c50c 100644 --- a/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc +++ b/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc @@ -51,7 +51,7 @@ When using this parameter internal requests are sent by using HTTP/1.1. ./bin/solr start -c -Dsolr.http1=true -z localhost:2481/solr -s /path/to/solr/home ---- + -Note the above command *must* be customized for your environment. The section <> has all the possible options. If you are running Solr as a service, you may prefer to review the section <>. +Note the above command *must* be customized for your environment. The section <> has all the possible options. If you are running Solr as a service, you may prefer to review the section <>. . When all nodes have been upgraded to 8.0, restart each one without the `-Dsolr.http1` parameter. @@ -59,7 +59,7 @@ Note the above command *must* be customized for your environment. The section << It is always strongly recommended that you fully reindex your documents after a major version upgrade. -Solr has a new section of the Reference Guide, <> which covers several strategies for how to reindex. +Solr has a new section of the Reference Guide, <> which covers several strategies for how to reindex. [#new-features-8] == New Features & Enhancements @@ -134,8 +134,8 @@ then you must do so with a delete-by-query technique. * Solr has a new field in the `\_default` configset, called `_nest_path_`. This field stores the path of the document in the hierarchy for non-root documents. -See the sections <> and -<> for more information +See the sections <> and +<> for more information and configuration details. [#config-changes-8] @@ -159,8 +159,8 @@ See also the section <> for mo * Memory codecs have been removed from Lucene (`MemoryPostings`, `MemoryDocValues`) and are no longer available in Solr. If you used `postingsFormat="Memory"` or `docValuesFormat="Memory"` on any field or field type configuration then either remove that setting to use the default or experiment with one of the other options. + -For more information on defining a codec, see the section <>; -for more information on field properties, see the section <>. +For more information on defining a codec, see the section <>; +for more information on field properties, see the section <>. *LowerCaseTokenizer* @@ -191,13 +191,13 @@ This syntax has been removed entirely and if sent to Solr it will now produce an The pattern language is very similar but not the same. Typically, simply update the pattern by changing an uppercase 'Z' to lowercase 'z' and that's it. + -For the current recommended set of patterns in schemaless mode, see the section <>, or simply examine the `_default` configset (found in `server/solr/configsets`). +For the current recommended set of patterns in schemaless mode, see the section <>, or simply examine the `_default` configset (found in `server/solr/configsets`). + Also note that the default set of date patterns (formats) have expanded from previous releases to subsume those patterns previously handled by the "extract" contrib (Solr Cell / Tika). *Solr Cell* -* The extraction contrib (<>) no longer does any date parsing, and thus no longer supports the `date.formats` parameter. To ensure date strings are properly parsed, use the `ParseDateFieldUpdateProcessorFactory` in your update chain. This update request processor is found by default with the "parse-date" update processor when running Solr in "<>". +* The extraction contrib (<>) no longer does any date parsing, and thus no longer supports the `date.formats` parameter. To ensure date strings are properly parsed, use the `ParseDateFieldUpdateProcessorFactory` in your update chain. This update request processor is found by default with the "parse-date" update processor when running Solr in "<>". *Langid Contrib* @@ -209,7 +209,7 @@ The following changes impact query behavior. *Highlighting* -* The Unified Highlighter parameter `hl.weightMatches` now defaults to `true`. See the section <> for more information about Highlighter parameters. +* The Unified Highlighter parameter `hl.weightMatches` now defaults to `true`. See the section <> for more information about Highlighter parameters. *eDisMax Query Parser* @@ -276,8 +276,8 @@ When upgrading to Solr 7.7.x, users should be aware of the following major chang *Admin UI* * The Admin UI now presents a login screen for any users with authentication enabled on their cluster. -Clusters with <> will prompt users to enter a username and password. -On clusters configured to use <>, authentication is handled transparently by the browser as before, but if authentication fails, users will be directed to configure their browser to provide an appropriate Kerberos ticket. +Clusters with <> will prompt users to enter a username and password. +On clusters configured to use <>, authentication is handled transparently by the browser as before, but if authentication fails, users will be directed to configure their browser to provide an appropriate Kerberos ticket. + The login screen's purpose is cosmetic only - Admin UI-triggered Solr requests were subject to authentication prior to 7.7 and still are today. The login screen changes only the user experience of providing this authentication. @@ -344,7 +344,7 @@ While most users are still encouraged to use the `NRTCachingDirectoryFactory`, w + For more information about the new directory factory, see the Jira issue https://issues.apache.org/jira/browse/LUCENE-8438[LUCENE-8438]. + -For more information about the directory factory configuration in Solr, see the section <>. +For more information about the directory factory configuration in Solr, see the section <>. === Solr 7.5 @@ -373,7 +373,7 @@ The `TieredMergePolicy` will also reclaim resources from segments that exceed `m * Solr's logging configuration file is now located in `server/resources/log4j2.xml` by default. -* A bug for Windows users has been corrected. When using Solr's examples (`bin/solr start -e`) log files will now be put in the correct location (`example/` instead of `server`). See also <> and <> for more information. +* A bug for Windows users has been corrected. When using Solr's examples (`bin/solr start -e`) log files will now be put in the correct location (`example/` instead of `server`). See also <> and <> for more information. === Solr 7.4 @@ -384,13 +384,13 @@ When upgrading to Solr 7.4, users should be aware of the following major changes *Logging* -* Solr now uses Log4j v2.11. The Log4j configuration is now in `log4j2.xml` rather than `log4j.properties` files. This is a server side change only and clients using SolrJ won't need any changes. Clients can still use any logging implementation which is compatible with SLF4J. We now let Log4j handle rotation of Solr logs at startup, and `bin/solr` start scripts will no longer attempt this nor move existing console or garbage collection logs into `logs/archived` either. See <> for more details about Solr logging. +* Solr now uses Log4j v2.11. The Log4j configuration is now in `log4j2.xml` rather than `log4j.properties` files. This is a server side change only and clients using SolrJ won't need any changes. Clients can still use any logging implementation which is compatible with SLF4J. We now let Log4j handle rotation of Solr logs at startup, and `bin/solr` start scripts will no longer attempt this nor move existing console or garbage collection logs into `logs/archived` either. See <> for more details about Solr logging. * Configuring `slowQueryThresholdMillis` now logs slow requests to a separate file named `solr_slow_requests.log`. Previously they would get logged in the `solr.log` file. *Legacy Scaling (non-SolrCloud)* -* In the <> of scaling Solr, a follower no longer commits an empty index when a completely new index is detected on leader during replication. To return to the previous behavior pass `false` to `skipCommitOnLeaderVersionZero` in the follower section of replication handler configuration, or pass it to the `fetchindex` command. +* In the <> of scaling Solr, a follower no longer commits an empty index when a completely new index is detected on leader during replication. To return to the previous behavior pass `false` to `skipCommitOnLeaderVersionZero` in the follower section of replication handler configuration, or pass it to the `fetchindex` command. If you are upgrading from a version earlier than Solr 7.3, please see previous version notes below. @@ -418,7 +418,7 @@ When upgrading to Solr 7.3, users should be aware of the following major changes *Logging* -* The default Solr log file size and number of backups have been raised to 32MB and 10 respectively. See the section <> for more information about how to configure logging. +* The default Solr log file size and number of backups have been raised to 32MB and 10 respectively. See the section <> for more information about how to configure logging. *SolrCloud* @@ -430,7 +430,7 @@ This means to upgrade to Solr 8 in the future, you will need to be on Solr 7.3 o *Spatial* -* If you are using the spatial JTS library with Solr, you must upgrade to 1.15.0. This new version of JTS is now dual-licensed to include a BSD style license. See the section on <> for more information. +* If you are using the spatial JTS library with Solr, you must upgrade to 1.15.0. This new version of JTS is now dual-licensed to include a BSD style license. See the section on <> for more information. *Highlighting* @@ -446,7 +446,7 @@ When upgrading to Solr 7.2, users should be aware of the following major changes *Local Parameters* -* Starting a query string with <> `{!myparser ...}` is used to switch from one query parser to another, and is intended for use by Solr system developers, not end users doing searches. To reduce negative side-effects of unintended hack-ability, Solr now limits the cases when local parameters will be parsed to only contexts in which the default parser is "<>" or "<>". +* Starting a query string with <> `{!myparser ...}` is used to switch from one query parser to another, and is intended for use by Solr system developers, not end users doing searches. To reduce negative side-effects of unintended hack-ability, Solr now limits the cases when local parameters will be parsed to only contexts in which the default parser is "<>" or "<>". + So, if `defType=edismax` then `q={!myparser ...}` won't work. In that example, put the desired query parser into the `defType` parameter. + @@ -503,4 +503,4 @@ See the section <> before starting your upgrade. +If you are upgrading from a version earlier than Solr 7.0, please see <> before starting your upgrade. 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 9c4e7fbb458..5804444bb6a 100644 --- a/solr/solr-ref-guide/src/making-and-restoring-backups.adoc +++ b/solr/solr-ref-guide/src/making-and-restoring-backups.adoc @@ -29,7 +29,7 @@ Likewise, committing changes using `openSearcher=false` may result in changes co == SolrCloud Backups -Support for backups when running SolrCloud is provided with the <>. This allows the backups to be generated across multiple shards, and restored to the same number of shards and replicas as the original collection. +Support for backups when running SolrCloud is provided with the <>. This allows the backups to be generated across multiple shards, and restored to the same number of shards and replicas as the original collection. NOTE: SolrCloud Backup/Restore requires a shared file system mounted at the same path on all nodes, or HDFS. @@ -227,7 +227,7 @@ The repository interfaces needs to be configured in the `solr.xml` file. While r If no repository is configured then the local filesystem repository will be used automatically. -Example `solr.xml` section to configure a repository like <>: +Example `solr.xml` section to configure a repository like <>: [source,xml] ---- diff --git a/solr/solr-ref-guide/src/managed-resources.adoc b/solr/solr-ref-guide/src/managed-resources.adoc index f1b17bcfba1..0bc186a6d46 100644 --- a/solr/solr-ref-guide/src/managed-resources.adoc +++ b/solr/solr-ref-guide/src/managed-resources.adoc @@ -99,7 +99,7 @@ Assuming you sent this request to Solr, the response body is a JSON document: } ---- -The `sample_techproducts_configs` <> ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly. +The `sample_techproducts_configs` <> ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly. One thing that should stand out to you in this response is that it contains a `managedList` of words as well as `initArgs`. This is an important concept in this framework -- managed resources typically have configuration and data. For stop words, the only configuration parameter is a boolean that determines whether to ignore the case of tokens during stop word filtering (ignoreCase=true|false). The data is a list of words, which is represented as a JSON array named `managedList` in the response. @@ -132,7 +132,7 @@ NOTE: PUT/POST is used to add terms to an existing list instead of replacing the === Managing Synonyms -For the most part, the API for managing synonyms behaves similar to the API for stop words, except instead of working with a list of words, it uses a map, where the value for each entry in the map is a set of synonyms for a term. As with stop words, the `sample_techproducts_configs` <> includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition in `schema.xml`: +For the most part, the API for managing synonyms behaves similar to the API for stop words, except instead of working with a list of words, it uses a map, where the value for each entry in the map is a set of synonyms for a term. As with stop words, the `sample_techproducts_configs` <> includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition in `schema.xml`: [source,xml] ---- @@ -208,7 +208,7 @@ Lastly, you can delete a mapping by sending a DELETE request to the managed endp Changes made to managed resources via this REST API are not applied to the active Solr components until the Solr collection (or Solr core in single server mode) is reloaded. -For example: after adding or deleting a stop word, you must reload the core/collection before changes become active; related APIs: <> and <>. +For example: after adding or deleting a stop word, you must reload the core/collection before changes become active; related APIs: <> and <>. This approach is required when running in distributed mode so that we are assured changes are applied to all cores in a collection at the same time so that behavior is consistent and predictable. It goes without saying that you don’t want one of your replicas working with a different set of stop words or synonyms than the others. @@ -218,7 +218,7 @@ However, the intent of this API implementation is that changes will be applied u [IMPORTANT] ==== -Changing things like stop words and synonym mappings typically require reindexing existing documents if being used by index-time analyzers. The RestManager framework does not guard you from this, it simply makes it possible to programmatically build up a set of stop words, synonyms, etc. See the section <> for more information about reindexing your documents. +Changing things like stop words and synonym mappings typically require reindexing existing documents if being used by index-time analyzers. The RestManager framework does not guard you from this, it simply makes it possible to programmatically build up a set of stop words, synonyms, etc. See the section <> for more information about reindexing your documents. ==== == RestManager Endpoint diff --git a/solr/solr-ref-guide/src/math-expressions.adoc b/solr/solr-ref-guide/src/math-expressions.adoc index cf10857281b..1edb7139e3b 100644 --- a/solr/solr-ref-guide/src/math-expressions.adoc +++ b/solr/solr-ref-guide/src/math-expressions.adoc @@ -25,44 +25,44 @@ image::images/math-expressions/searchiris.png[] == Table of Contents -*<>*: Gallery of streaming expression and math expression visualizations. +*<>*: Gallery of streaming expression and math expression visualizations. -*<>*: Getting started with streaming expressions, math expressions, and visualization. +*<>*: Getting started with streaming expressions, math expressions, and visualization. -*<>*: Visualizing, transforming and loading CSV files. +*<>*: Visualizing, transforming and loading CSV files. -*<>*: Searching, sampling, aggregation and visualization of result sets. +*<>*: Searching, sampling, aggregation and visualization of result sets. -*<>*: Transforming and filtering result sets. +*<>*: Transforming and filtering result sets. -*<>*: Math functions and visualization applied to numbers. +*<>*: Math functions and visualization applied to numbers. -*<>*: Vector math, manipulation and visualization. +*<>*: Vector math, manipulation and visualization. -*<>*: Vectorizing result sets and assigning and visualizing variables. +*<>*: Vectorizing result sets and assigning and visualizing variables. -*<>*: Matrix math, manipulation and visualization. +*<>*: Matrix math, manipulation and visualization. -*<>*: Text analysis and TF-IDF term vectors. +*<>*: Text analysis and TF-IDF term vectors. -*<>*: Continuous and discrete probability distribution functions. +*<>*: Continuous and discrete probability distribution functions. -*<>*: Descriptive statistics, histograms, percentiles, correlation, inference tests and other stats functions. +*<>*: Descriptive statistics, histograms, percentiles, correlation, inference tests and other stats functions. -*<>*: Simple and multivariate linear regression. +*<>*: Simple and multivariate linear regression. -*<>*: Polynomial, harmonic and Gaussian curve fitting. +*<>*: Polynomial, harmonic and Gaussian curve fitting. -*<>*: Time series aggregation, visualization, smoothing, differencing, anomaly detection and forecasting. +*<>*: Time series aggregation, visualization, smoothing, differencing, anomaly detection and forecasting. -*<>*: Interpolation, derivatives and integrals. +*<>*: Interpolation, derivatives and integrals. -*<>*: Convolution, cross-correlation, autocorrelation and fast Fourier transforms. +*<>*: Convolution, cross-correlation, autocorrelation and fast Fourier transforms. -*<>*: Monte Carlo simulations and random walks +*<>*: Monte Carlo simulations and random walks -*<>*: Distance, KNN, DBSCAN, K-means, fuzzy K-means and other ML functions. +*<>*: Distance, KNN, DBSCAN, K-means, fuzzy K-means and other ML functions. -*<>*: Convex Hulls and Enclosing Disks. +*<>*: Convex Hulls and Enclosing Disks. -*<>*: Solr log analytics and visualization. +*<>*: Solr log analytics and visualization. diff --git a/solr/solr-ref-guide/src/mbean-request-handler.adoc b/solr/solr-ref-guide/src/mbean-request-handler.adoc index f7767bfab56..2deeba22cae 100644 --- a/solr/solr-ref-guide/src/mbean-request-handler.adoc +++ b/solr/solr-ref-guide/src/mbean-request-handler.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -The MBean Request Handler offers programmatic access to the information provided on the <> page of the Admin UI. +The MBean Request Handler offers programmatic access to the information provided on the <> page of the Admin UI. The MBean Request Handler accepts the following parameters: @@ -30,7 +30,7 @@ Restricts results by category name. Specifies whether statistics are returned with results. You can override the `stats` parameter on a per-field basis. The default is `false`. `wt`:: -The output format. This operates the same as the <>. The default is `json`. +The output format. This operates the same as the <>. The default is `json`. == MBeanRequestHandler Examples diff --git a/solr/solr-ref-guide/src/metrics-reporting.adoc b/solr/solr-ref-guide/src/metrics-reporting.adoc index b6830b1c9ec..73c244322bd 100644 --- a/solr/solr-ref-guide/src/metrics-reporting.adoc +++ b/solr/solr-ref-guide/src/metrics-reporting.adoc @@ -95,7 +95,7 @@ In the future, metrics will be added for shard leaders and cluster nodes, includ The metrics available in your system can be customized by modifying the `` element in `solr.xml`. -TIP: See also the section <> for more information about the `solr.xml` file, where to find it, and how to edit it. +TIP: See also the section <> for more information about the `solr.xml` file, where to find it, and how to edit it. === Disabling the Metrics Collection The `` element in `solr.xml` supports one attribute `enabled`, which takes a boolean value, diff --git a/solr/solr-ref-guide/src/monitoring-solr-with-prometheus-and-grafana.adoc b/solr/solr-ref-guide/src/monitoring-solr-with-prometheus-and-grafana.adoc index 6a21c81df44..e5bf09ec510 100644 --- a/solr/solr-ref-guide/src/monitoring-solr-with-prometheus-and-grafana.adoc +++ b/solr/solr-ref-guide/src/monitoring-solr-with-prometheus-and-grafana.adoc @@ -18,7 +18,7 @@ If you use https://prometheus.io[Prometheus] and https://grafana.com[Grafana] for metrics storage and data visualization, Solr includes a Prometheus exporter to collect metrics and other data. -A Prometheus exporter (`solr-exporter`) allows users to monitor not only Solr metrics which come from <>, but also facet counts which come from <> and responses to <> commands and <> requests. +A Prometheus exporter (`solr-exporter`) allows users to monitor not only Solr metrics which come from <>, but also facet counts which come from <> and responses to <> commands and <> requests. This graphic provides a more detailed view: @@ -143,11 +143,11 @@ All <<#command-line-parameters,command line parameters>> are able to be provided === Getting Metrics from a Secured SolrCloud -Your SolrCloud might be secured by measures described in <>. -The security configuration can be injected into `solr-exporter` using environment variables in a fashion similar to other clients using <>. +Your SolrCloud might be secured by measures described in <>. +The security configuration can be injected into `solr-exporter` using environment variables in a fashion similar to other clients using <>. This is possible because the main script picks up <> and passes them on to the Java process. -Example for a SolrCloud instance secured by <>, <> and <>: +Example for a SolrCloud instance secured by <>, <> and <>: Suppose you have a file `basicauth.properties` with the Solr Basic-Auth credentials: @@ -319,10 +319,10 @@ The `solr-exporter` configuration file always starts and closes with two simple Between these elements, the data the `solr-exporter` should request is defined. There are several possible types of requests to make: [horizontal] -``:: Scrape the response to a <> request. +``:: Scrape the response to a <> request. ``:: Scrape the response to a <> request. -``:: Scrape the response to a <> request. -``:: Scrape the response to a <> request. +``:: Scrape the response to a <> request. +``:: Scrape the response to a <> request. Within each of these types, we need to define the query and how to work with the response. To do this, we define two additional elements: diff --git a/solr/solr-ref-guide/src/monitoring-solr.adoc b/solr/solr-ref-guide/src/monitoring-solr.adoc index d951c30fa19..bee3cab1b87 100644 --- a/solr/solr-ref-guide/src/monitoring-solr.adoc +++ b/solr/solr-ref-guide/src/monitoring-solr.adoc @@ -22,20 +22,20 @@ Administration and monitoring can be performed using the web-based administratio Common administrative tasks include: -<>: Details of Solr's metrics registries and Metrics API. +<>: Details of Solr's metrics registries and Metrics API. -<>: Metrics history collection, configuration and API. +<>: Metrics history collection, configuration and API. -<>: How to use Solr's MBeans for programmatic access to the system plugins and stats. +<>: How to use Solr's MBeans for programmatic access to the system plugins and stats. -<>: Describes how to configure logging for Solr. +<>: Describes how to configure logging for Solr. -<>: Describes how to use Java Management Extensions with Solr. +<>: Describes how to use Java Management Extensions with Solr. -<>: Describes how to monitor Solr with Prometheus and Grafana. +<>: Describes how to monitor Solr with Prometheus and Grafana. -<>: Additional information on statistics returned from JMX. +<>: Additional information on statistics returned from JMX. -<>: Describes how to do distributed tracing for Solr requests. +<>: Describes how to do distributed tracing for Solr requests. diff --git a/solr/solr-ref-guide/src/morelikethis.adoc b/solr/solr-ref-guide/src/morelikethis.adoc index 4625c5fde1c..941eb5e907a 100644 --- a/solr/solr-ref-guide/src/morelikethis.adoc +++ b/solr/solr-ref-guide/src/morelikethis.adoc @@ -74,7 +74,7 @@ Sets the maximum number of tokens to parse in each example document field that i Specifies if the query will be boosted by the interesting term relevance. It can be either "true" or "false". `mlt.qf`:: -Query fields and their boosts using the same format as that used by the <>. These fields must also be specified in `mlt.fl`. +Query fields and their boosts using the same format as that used by the <>. These fields must also be specified in `mlt.fl`. == Parameters for the MoreLikeThisComponent @@ -109,4 +109,4 @@ Unless `mlt.boost=true`, all terms will have `boost=1.0`. == MoreLikeThis Query Parser -The `mlt` query parser provides a mechanism to retrieve documents similar to a given document, like the handler. More information on the usage of the mlt query parser can be found in the section <>. +The `mlt` query parser provides a mechanism to retrieve documents similar to a given document, like the handler. More information on the usage of the mlt query parser can be found in the section <>. diff --git a/solr/solr-ref-guide/src/other-parsers.adoc b/solr/solr-ref-guide/src/other-parsers.adoc index ca25e419843..e714f12aea0 100644 --- a/solr/solr-ref-guide/src/other-parsers.adoc +++ b/solr/solr-ref-guide/src/other-parsers.adoc @@ -20,11 +20,11 @@ In addition to the main query parsers discussed earlier, there are several other This section details the other parsers, and gives examples for how they might be used. -Many of these parsers are expressed the same way as <>. +Many of these parsers are expressed the same way as <>. == Block Join Query Parsers -There are two query parsers that support block joins. These parsers allow indexing and searching for relational content that has been <>. +There are two query parsers that support block joins. These parsers allow indexing and searching for relational content that has been <>. The example usage of the query parsers below assumes the following documents have been indexed: @@ -297,7 +297,7 @@ The `CollapsingQParser` is really a _post filter_ that provides more performant This parser collapses the result set to a single document per group before it forwards the result set to the rest of the search components. So all downstream components (faceting, highlighting, etc.) will work with the collapsed result set. -Details about using the `CollapsingQParser` can be found in the section <>. +Details about using the `CollapsingQParser` can be found in the section <>. == Complex Phrase Query Parser @@ -406,7 +406,7 @@ q=+field:text +COLOR:Red +SIZE:XL == Function Query Parser -The `FunctionQParser` extends the `QParserPlugin` and creates a function query from the input value. This is only one way to use function queries in Solr; for another, more integrated, approach, see the section on <>. +The `FunctionQParser` extends the `QParserPlugin` and creates a function query from the input value. This is only one way to use function queries in Solr; for another, more integrated, approach, see the section on <>. Example: @@ -484,7 +484,7 @@ Boolean that indicates if the results of the query should be filtered so that on === Graph Query Limitations -The `graph` parser only works in single node Solr installations, or with <> collections that use exactly 1 shard. +The `graph` parser only works in single node Solr installations, or with <> collections that use exactly 1 shard. === Graph Query Examples @@ -890,7 +890,7 @@ Example: {!ltr model=myModel reRankDocs=100} ---- -Details about using the `LTRQParserPlugin` can be found in the <> section. +Details about using the `LTRQParserPlugin` can be found in the <> section. == Max Score Query Parser @@ -1082,7 +1082,7 @@ http://localhost:8983/solr/techproducts?q=memory _query_:{!rank f='pagerank', fu The `ReRankQParserPlugin` is a special purpose parser for Re-Ranking the top results of a simple query using a more complex ranking query. -Details about using the `ReRankQParserPlugin` can be found in the <> section. +Details about using the `ReRankQParserPlugin` can be found in the <> section. == Simple Query Parser @@ -1136,7 +1136,7 @@ Any errors in syntax are ignored and the query parser will interpret queries as There are two spatial QParsers in Solr: `geofilt` and `bbox`. But there are other ways to query spatially: using the `frange` parser with a distance function, using the standard (lucene) query parser with the range syntax to pick the corners of a rectangle, or with RPT and BBoxField you can use the standard query parser but use a special syntax within quotes that allows you to pick the spatial predicate. -All these options are documented further in the section <>. +All these options are documented further in the section <>. == Surround Query Parser @@ -1232,7 +1232,7 @@ If no analysis or transformation is desired for any type of field, see the <> but takes in multiple values separated by commas and returns documents matching any of the specified values. -This can be useful for generating filter queries from the external human readable terms returned by the faceting or terms components, and may be more efficient in some cases than using the <> to generate a boolean query since the default implementation `method` avoids scoring. +This can be useful for generating filter queries from the external human readable terms returned by the faceting or terms components, and may be more efficient in some cases than using the <> to generate a boolean query since the default implementation `method` avoids scoring. This query parser takes the following parameters: diff --git a/solr/solr-ref-guide/src/overview-of-documents-fields-and-schema-design.adoc b/solr/solr-ref-guide/src/overview-of-documents-fields-and-schema-design.adoc index bdc3ff23380..8fd9bdf98c9 100644 --- a/solr/solr-ref-guide/src/overview-of-documents-fields-and-schema-design.adoc +++ b/solr/solr-ref-guide/src/overview-of-documents-fields-and-schema-design.adoc @@ -46,16 +46,16 @@ However, a biography will likely contains lots of words you don't care about and The solution to both these problems is field analysis. For the biography field, you can tell Solr how to break apart the biography into words. You can tell Solr that you want to make all the words lower case, and you can tell Solr to remove accents marks. -Field analysis is an important part of a field type. <> is a detailed description of field analysis. +Field analysis is an important part of a field type. <> is a detailed description of field analysis. == Solr's Schema File Solr stores details about the field types and fields it is expected to understand in a schema file. The name and location of this file may vary depending on how you initially configured Solr or if you modified it later. -* `managed-schema` is the name for the schema file Solr uses by default to support making Schema changes at runtime via the <>, or <> features. You may <> to use an alternative filename if you choose, but the contents of the files are still updated automatically by Solr. -* `schema.xml` is the traditional name for a schema file which can be edited manually by users who use the <>. -* If you are using SolrCloud you may not be able to find any file by these names on the local filesystem. You will only be able to see the schema through the Schema API (if enabled) or through the Solr Admin UI's <>. +* `managed-schema` is the name for the schema file Solr uses by default to support making Schema changes at runtime via the <>, or <> features. You may <> to use an alternative filename if you choose, but the contents of the files are still updated automatically by Solr. +* `schema.xml` is the traditional name for a schema file which can be edited manually by users who use the <>. +* If you are using SolrCloud you may not be able to find any file by these names on the local filesystem. You will only be able to see the schema through the Schema API (if enabled) or through the Solr Admin UI's <>. Whichever name of the file in use in your installation, the structure of the file is not changed. However, the way you interact with the file will change. If you are using the managed schema, it is expected that you only interact with the file with the Schema API, and never make manual edits. If you do not use the managed schema, you will only be able to make manual edits to the file, the Schema API will not support any modifications. -Note that if you are not using the Schema API yet you do use SolrCloud, you will need to interact with `schema.xml` through ZooKeeper using upconfig and downconfig commands to make a local copy and upload your changes. The options for doing this are described in <> and <>. +Note that if you are not using the Schema API yet you do use SolrCloud, you will need to interact with `schema.xml` through ZooKeeper using upconfig and downconfig commands to make a local copy and upload your changes. The options for doing this are described in <> and <>. diff --git a/solr/solr-ref-guide/src/overview-of-searching-in-solr.adoc b/solr/solr-ref-guide/src/overview-of-searching-in-solr.adoc index 4de2b399288..7ed075d9e63 100644 --- a/solr/solr-ref-guide/src/overview-of-searching-in-solr.adoc +++ b/solr/solr-ref-guide/src/overview-of-searching-in-solr.adoc @@ -22,9 +22,9 @@ When a user runs a search in Solr, the search query is processed by a *request h Search applications select a particular request handler by default. In addition, applications can be configured to allow users to override the default selection in preference of a different request handler. -To process a search query, a request handler calls a *query parser*, which interprets the terms and parameters of a query. Different query parsers support different syntax. Solr's default query parser is known as the <>,or more commonly just the "lucene" query parser. Solr also includes the <>query parser, and the <> (eDisMax) query parser. The <> query parser's syntax allows for greater precision in searches, but the DisMax query parser is much more tolerant of errors. The DisMax query parser is designed to provide an experience similar to that of popular search engines such as Google, which rarely display syntax errors to users. The Extended DisMax query parser is an improved version of DisMax that handles the full Lucene query syntax while still tolerating syntax errors. It also includes several additional features. +To process a search query, a request handler calls a *query parser*, which interprets the terms and parameters of a query. Different query parsers support different syntax. Solr's default query parser is known as the <>,or more commonly just the "lucene" query parser. Solr also includes the <>query parser, and the <> (eDisMax) query parser. The <> query parser's syntax allows for greater precision in searches, but the DisMax query parser is much more tolerant of errors. The DisMax query parser is designed to provide an experience similar to that of popular search engines such as Google, which rarely display syntax errors to users. The Extended DisMax query parser is an improved version of DisMax that handles the full Lucene query syntax while still tolerating syntax errors. It also includes several additional features. -In addition, there are <> that are accepted by all query parsers. +In addition, there are <> that are accepted by all query parsers. Input to a query parser can include: @@ -34,13 +34,13 @@ Input to a query parser can include: Search parameters may also specify a *filter query*. As part of a search response, a filter query runs a query against the entire index and caches the results. Because Solr allocates a separate cache for filter queries, the strategic use of filter queries can improve search performance. (Despite their similar names, query filters are not related to analysis filters. Filter queries perform queries at search time against data already in the index, while analysis filters, such as Tokenizers, parse content for indexing, following specified rules). -A search query can request that certain terms be highlighted in the search response; that is, the selected terms will be displayed in colored boxes so that they "jump out" on the screen of search results. <> can make it easier to find relevant passages in long documents returned in a search. Solr supports multi-term highlighting. Solr includes a rich set of search parameters for controlling how terms are highlighted. +A search query can request that certain terms be highlighted in the search response; that is, the selected terms will be displayed in colored boxes so that they "jump out" on the screen of search results. <> can make it easier to find relevant passages in long documents returned in a search. Solr supports multi-term highlighting. Solr includes a rich set of search parameters for controlling how terms are highlighted. Search responses can also be configured to include *snippets* (document excerpts) featuring highlighted text. Popular search engines such as Google and Yahoo! return snippets in their search results: 3-4 lines of text offering a description of a search result. To help users zero in on the content they're looking for, Solr supports two special ways of grouping search results to aid further exploration: faceting and clustering. -<> is the arrangement of search results into categories (which are based on indexed terms). Within each category, Solr reports on the number of hits for relevant term, which is called a facet constraint. Faceting makes it easy for users to explore search results on sites such as movie sites and product review sites, where there are many categories and many items within a category. +<> is the arrangement of search results into categories (which are based on indexed terms). Within each category, Solr reports on the number of hits for relevant term, which is called a facet constraint. Faceting makes it easy for users to explore search results on sites such as movie sites and product review sites, where there are many categories and many items within a category. The screen shot below shows an example of faceting from the CNET Web site (CBS Interactive Inc.), which was the first site to use Solr. @@ -50,9 +50,9 @@ Faceting makes use of fields defined when the search applications were indexed. *Clustering* groups search results by similarities discovered when a search is executed, rather than when content is indexed. The results of clustering often lack the neat hierarchical organization found in faceted search results, but clustering can be useful nonetheless. It can reveal unexpected commonalities among search results, and it can help users rule out content that isn't pertinent to what they're really searching for. -Solr also supports a feature called <>, which enables users to submit new queries that focus on particular terms returned in an earlier query. MoreLikeThis queries can make use of faceting or clustering to provide additional aid to users. +Solr also supports a feature called <>, which enables users to submit new queries that focus on particular terms returned in an earlier query. MoreLikeThis queries can make use of faceting or clustering to provide additional aid to users. -A Solr component called a <> manages the final presentation of the query response. Solr includes a variety of response writers, including an <> and a <>. +A Solr component called a <> manages the final presentation of the query response. Solr includes a variety of response writers, including an <> and a <>. The diagram below summarizes some key elements of the search process. diff --git a/solr/solr-ref-guide/src/overview-of-the-solr-admin-ui.adoc b/solr/solr-ref-guide/src/overview-of-the-solr-admin-ui.adoc index 5f8ca6af0fc..262ce39823d 100644 --- a/solr/solr-ref-guide/src/overview-of-the-solr-admin-ui.adoc +++ b/solr/solr-ref-guide/src/overview-of-the-solr-admin-ui.adoc @@ -27,11 +27,11 @@ image::images/overview-of-the-solr-admin-ui/dashboard.png[image,height=400] The left-side of the screen is a menu under the Solr logo that provides the navigation through the screens of the UI. -The first set of links are for system-level information and configuration and provide access to <>, <>, and <>, among other things. +The first set of links are for system-level information and configuration and provide access to <>, <>, and <>, among other things. At the end of this information is at least one pulldown listing Solr cores configured for this instance. -On <> nodes, an additional pulldown list shows all collections in this cluster. -Clicking on a collection or core name shows secondary menus of information for the specified collection or core, such as a <>, <>, <>, and an ability to perform <> on indexed data. +On <> nodes, an additional pulldown list shows all collections in this cluster. +Clicking on a collection or core name shows secondary menus of information for the specified collection or core, such as a <>, <>, <>, and an ability to perform <> on indexed data. The left-side navigation appears on every screen, while the center changes to the detail of the option selected. The Dashboard shows several information items in the center of the screen, including system uptime, the version being run, system-level data, JVM arguments, and the security plugins enabled (if any). @@ -51,7 +51,7 @@ If authentication has been enabled, Solr will present a login screen to unauthen image::images/overview-of-the-solr-admin-ui/login.png[] This login screen currently only works with Basic Authentication. -See the section <> for +See the section <> for details on how to configure Solr to use this method of authentication. Once logged in, the left-hand navigation will show the current user with an option to logout. @@ -77,7 +77,7 @@ These icons include the following links. |Issue Tracker |Navigates to the JIRA issue tracking server for the Apache Solr project. This server resides at https://issues.apache.org/jira/browse/SOLR. |IRC Channel |Navigates to Solr's http://en.wikipedia.org/wiki/Internet_Relay_Chat[IRC] live-chat room: http://webchat.freenode.net/?channels=#solr. |Community forum |Navigates to the Apache Wiki page which has further information about ways to engage in the Solr User community mailing lists: https://cwiki.apache.org/confluence/display/solr/UsingMailingLists. -|Solr Query Syntax |Navigates to the section <> in this Reference Guide. +|Solr Query Syntax |Navigates to the section <> in this Reference Guide. |=== These links cannot be modified without editing the `index.html` in the `server/solr/solr-webapp` directory that contains the Admin UI files. diff --git a/solr/solr-ref-guide/src/package-manager.adoc b/solr/solr-ref-guide/src/package-manager.adoc index 7f9b55f1d16..4d2f0bf0b44 100644 --- a/solr/solr-ref-guide/src/package-manager.adoc +++ b/solr/solr-ref-guide/src/package-manager.adoc @@ -19,14 +19,14 @@ The package manager in Solr allows installation and updating of Solr-specific packages in Solr's cluster environment. -In this system, a _package_ is a set of Java jar files (usually one) containing one or more <>. Each jar file is also accompanied by a signature string (which can be verified against a supplied public key). +In this system, a _package_ is a set of Java jar files (usually one) containing one or more <>. Each jar file is also accompanied by a signature string (which can be verified against a supplied public key). A key design aspect of this system is the ability to install or update packages in a cluster environment securely without the need to restart every node. Other elements of the design include the ability to install from a remote repository; package standardization; a command line interface (CLI); and a package store. This section will focus on how to use the package manager to install and update packages. -For technical details, see the section <>. +For technical details, see the section <>. == Interacting with the Package Manager @@ -48,7 +48,7 @@ $ bin/solr -c -Denable.packages=true ---- WARNING: There are security consequences to enabling the package manager. -If an unauthorized user gained access to the system, they would have write access to ZooKeeper and could install packages from untrusted sources. Always ensure you have secured Solr with firewalls and <> before enabling the package manager. +If an unauthorized user gained access to the system, they would have write access to ZooKeeper and could install packages from untrusted sources. Always ensure you have secured Solr with firewalls and <> before enabling the package manager. === Add Trusted Repositories @@ -122,7 +122,7 @@ For example, if a package named `mypackage` contains a request handler, we would ---- -Then use either the Collections API <> or the <> to reload the collection. +Then use either the Collections API <> or the <> to reload the collection. Next, set the package version that this collection is using. If the collection is named `collection1`, the package name is `mypackage`, and the installed version is `1.0.0`, the command would look like this: diff --git a/solr/solr-ref-guide/src/pagination-of-results.adoc b/solr/solr-ref-guide/src/pagination-of-results.adoc index 2bc420a6d20..abfbdd9cdaa 100644 --- a/solr/solr-ref-guide/src/pagination-of-results.adoc +++ b/solr/solr-ref-guide/src/pagination-of-results.adoc @@ -105,7 +105,7 @@ When the `responseHeader` no longer includes `"partialResults": true`, and `curs . `sort` clauses must include the uniqueKey field (either `asc` or `desc`). + 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 <> 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. +. Sorts including <> 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 <> in all of your cursor requests. @@ -270,4 +270,4 @@ while (true) { } ---- -TIP: For certain specialized cases, the <> may be an option. +TIP: For certain specialized cases, the <> may be an option. diff --git a/solr/solr-ref-guide/src/parallel-sql-interface.adoc b/solr/solr-ref-guide/src/parallel-sql-interface.adoc index 3c4ea088cdf..e1ddd4f43cc 100644 --- a/solr/solr-ref-guide/src/parallel-sql-interface.adoc +++ b/solr/solr-ref-guide/src/parallel-sql-interface.adoc @@ -23,7 +23,7 @@ The SQL interface seamlessly combines SQL with Solr's full-text search capabilit == SQL Architecture -The SQL interface allows sending a SQL query to Solr and getting documents streamed back in response. Under the covers, Solr's SQL interface uses the Apache Calcite SQL engine to translate SQL queries to physical query plans implemented as <>. +The SQL interface allows sending a SQL query to Solr and getting documents streamed back in response. Under the covers, Solr's SQL interface uses the Apache Calcite SQL engine to translate SQL queries to physical query plans implemented as <>. === Solr Collections and DB Tables @@ -73,7 +73,7 @@ As described below in the section <>, you may want to set up a s === /stream and /export Request Handlers -The Streaming API is an extensible parallel computing framework for SolrCloud. <> provide a query language and a serialization format for the Streaming API. +The Streaming API is an extensible parallel computing framework for SolrCloud. <> provide a query language and a serialization format for the Streaming API. The Streaming API provides support for fast MapReduce allowing it to perform parallel relational algebra on extremely large data sets. Under the covers the SQL interface parses SQL queries using the Apache Calcite SQL Parser. It then translates the queries to the parallel query plan. The parallel query plan is expressed using the Streaming API and Streaming Expressions. @@ -290,7 +290,7 @@ SELECT distinct fieldA as fa, fieldB as fb FROM tableA ORDER BY fa desc, fb desc The SQL interface supports simple statistics calculated on numeric fields. The supported functions are `count(*)`, `min`, `max`, `sum`, and `avg`. -Because these functions never require data to be shuffled, the aggregations are pushed down into the search engine and are generated by the <>. +Because these functions never require data to be shuffled, the aggregations are pushed down into the search engine and are generated by the <>. [source,sql] ---- @@ -415,20 +415,20 @@ There are other parameters that can be optionally added to the connection string === DbVisualizer -A step-by-step guide for setting up https://www.dbvis.com/[DbVisualizer] is in the section <>. +A step-by-step guide for setting up https://www.dbvis.com/[DbVisualizer] is in the section <>. === SQuirreL SQL -A step-by-step guide for setting up http://squirrel-sql.sourceforge.net[SQuirreL SQL] is in the section <>. +A step-by-step guide for setting up http://squirrel-sql.sourceforge.net[SQuirreL SQL] is in the section <>. === Apache Zeppelin (incubating) -A step-by-step guide for setting up http://zeppelin.apache.org/[Apache Zeppelin] is in the section <>. +A step-by-step guide for setting up http://zeppelin.apache.org/[Apache Zeppelin] is in the section <>. === Python/Jython -Examples of using Python and Jython for connecting to Solr with the Solr JDBC driver are available in the section <>. +Examples of using Python and Jython for connecting to Solr with the Solr JDBC driver are available in the section <>. === R -Examples of using R for connecting to Solr with the Solr JDBC driver are available in the section <>. +Examples of using R for connecting to Solr with the Solr JDBC driver are available in the section <>. diff --git a/solr/solr-ref-guide/src/parameter-reference.adoc b/solr/solr-ref-guide/src/parameter-reference.adoc index 9a3e9a08340..2b2a6fd9818 100644 --- a/solr/solr-ref-guide/src/parameter-reference.adoc +++ b/solr/solr-ref-guide/src/parameter-reference.adoc @@ -51,6 +51,6 @@ Defaults to 15000. The time a client is allowed to not talk to ZooKeeper before == SolrCloud Core Parameters `shard`:: -Defaults to being automatically assigned based on numShards. Specifies which shard this core acts as a replica of. `shard` can be specified in the <> for each core. +Defaults to being automatically assigned based on numShards. Specifies which shard this core acts as a replica of. `shard` can be specified in the <> for each core. -Additional cloud related parameters are discussed in <> +Additional cloud related parameters are discussed in <> diff --git a/solr/solr-ref-guide/src/performance-statistics-reference.adoc b/solr/solr-ref-guide/src/performance-statistics-reference.adoc index ed8bae0bb24..34694cfa2ba 100644 --- a/solr/solr-ref-guide/src/performance-statistics-reference.adoc +++ b/solr/solr-ref-guide/src/performance-statistics-reference.adoc @@ -18,7 +18,7 @@ This page explains some of the statistics that Solr exposes. -There are two approaches to retrieving metrics. First, you can use the <>, or you can enable JMX and get metrics from the <> or via an external tool such as JConsole. The below descriptions focus on retrieving the metrics using the Metrics API, but the metric names are the same if using the MBean Request Handler or an external tool. +There are two approaches to retrieving metrics. First, you can use the <>, or you can enable JMX and get metrics from the <> or via an external tool such as JConsole. The below descriptions focus on retrieving the metrics using the Metrics API, but the metric names are the same if using the MBean Request Handler or an external tool. These statistics are per core. When you are running in SolrCloud mode these statistics would co-relate to the performance of an individual replica. @@ -220,4 +220,4 @@ When eviction by heap usage is enabled, the following additional statistics are |evictionsRamUsage| Number of cache evictions for the current index searcher because heap usage exceeded maxRamMB. |=== -More information on Solr caches is available in the section <>. +More information on Solr caches is available in the section <>. diff --git a/solr/solr-ref-guide/src/ping.adoc b/solr/solr-ref-guide/src/ping.adoc index ed4e7ce481b..39e8a07c80b 100644 --- a/solr/solr-ref-guide/src/ping.adoc +++ b/solr/solr-ref-guide/src/ping.adoc @@ -21,7 +21,7 @@ Choosing Ping under a core name issues a `ping` request to check whether the cor .Ping Option in Core Dropdown image::images/ping/ping.png[image,width=171,height=195] -The search executed by a Ping is configured with the <>. See <> for the paramset to use for the `/admin/ping` endpoint. +The search executed by a Ping is configured with the <>. See <> for the paramset to use for the `/admin/ping` endpoint. The Ping option doesn't open a page, but the status of the request can be seen on the core overview page shown when clicking on a collection name. The length of time the request has taken is displayed next to the Ping option, in milliseconds. diff --git a/solr/solr-ref-guide/src/putting-the-pieces-together.adoc b/solr/solr-ref-guide/src/putting-the-pieces-together.adoc index 1c9e96624c6..8cc175c4764 100644 --- a/solr/solr-ref-guide/src/putting-the-pieces-together.adoc +++ b/solr/solr-ref-guide/src/putting-the-pieces-together.adoc @@ -44,7 +44,7 @@ Note that the `types` and `fields` sections are optional, meaning you are free t == Choosing Appropriate Numeric Types -For general numeric needs, consider using one of the `IntPointField`, `LongPointField`, `FloatPointField`, or `DoublePointField` classes, depending on the specific values you expect. These "Dimensional Point" based numeric classes use specially encoded data structures to support efficient range queries regardless of the size of the ranges used. Enable <> on these fields as needed for sorting and/or faceting. +For general numeric needs, consider using one of the `IntPointField`, `LongPointField`, `FloatPointField`, or `DoublePointField` classes, depending on the specific values you expect. These "Dimensional Point" based numeric classes use specially encoded data structures to support efficient range queries regardless of the size of the ranges used. Enable <> on these fields as needed for sorting and/or faceting. Some Solr features may not yet work with "Dimensional Points", in which case you may want to consider the equivalent `TrieIntField`, `TrieLongField`, `TrieFloatField`, and `TrieDoubleField` classes. These field types are deprecated and are likely to be removed in a future major Solr release, but they can still be used if necessary. Configure a `precisionStep="0"` if you wish to minimize index size, but if you expect users to make frequent range queries on numeric types, use the default `precisionStep` (by not specifying it) or specify it as `precisionStep="8"` (which is the default). This offers faster speed for range queries at the expense of increasing index size. diff --git a/solr/solr-ref-guide/src/query-re-ranking.adoc b/solr/solr-ref-guide/src/query-re-ranking.adoc index 35b8fbf2369..2e38f0a50f2 100644 --- a/solr/solr-ref-guide/src/query-re-ranking.adoc +++ b/solr/solr-ref-guide/src/query-re-ranking.adoc @@ -42,7 +42,7 @@ Three rank queries are currently included in the Solr distribution. You can also The `rerank` parser wraps a query specified by an local parameter, along with additional parameters indicating how many documents should be re-ranked, and how the final scores should be computed: `reRankQuery`:: -The query string for your complex ranking query - in most cases <> will be used to refer to another request parameter. This parameter is required. +The query string for your complex ranking query - in most cases <> will be used to refer to another request parameter. This parameter is required. `reRankDocs`:: The number of top N documents from the original query that should be re-ranked. This number will be treated as a minimum, and may be increased internally automatically in order to rank enough documents to satisfy the query (i.e., start+rows). The default is `200`. @@ -61,8 +61,8 @@ If a document matches the original query, but does not match the re-ranking quer === LTR Query Parser -The `ltr` stands for Learning To Rank, please see <> for more detailed information. +The `ltr` stands for Learning To Rank, please see <> for more detailed information. == Combining Ranking Queries with Other Solr Features -The `rq` parameter and the re-ranking feature in general works well with other Solr features. For example, it can be used in conjunction with the <> to re-rank the group heads after they've been collapsed. It also preserves the order of documents elevated by the <>. And it even has its own custom explain so you can see how the re-ranking scores were derived when looking at <>. +The `rq` parameter and the re-ranking feature in general works well with other Solr features. For example, it can be used in conjunction with the <> to re-rank the group heads after they've been collapsed. It also preserves the order of documents elevated by the <>. And it even has its own custom explain so you can see how the re-ranking scores were derived when looking at <>. diff --git a/solr/solr-ref-guide/src/query-screen.adoc b/solr/solr-ref-guide/src/query-screen.adoc index 4f66170c98d..87a36f5e174 100644 --- a/solr/solr-ref-guide/src/query-screen.adoc +++ b/solr/solr-ref-guide/src/query-screen.adoc @@ -37,19 +37,19 @@ Request-handler (qt):: Specifies the query handler for the request. If a query handler is not specified, Solr processes the response with the standard query handler. q:: -The query event. See <> for an explanation of this parameter. +The query event. See <> for an explanation of this parameter. fq:: -The filter queries. See <> for more information on this parameter. +The filter queries. See <> for more information on this parameter. sort:: Sorts the response to a query in either ascending or descending order based on the response's score or another specified characteristic. start, rows:: -`start` is the offset into the query result starting at which documents should be returned. The default value is 0, meaning that the query should return results starting with the first document that matches. This field accepts the same syntax as the start query parameter, which is described in <>. `rows` is the number of rows to return. +`start` is the offset into the query result starting at which documents should be returned. The default value is 0, meaning that the query should return results starting with the first document that matches. This field accepts the same syntax as the start query parameter, which is described in <>. `rows` is the number of rows to return. fl:: -Defines the fields to return for each document. You can explicitly list the stored fields, <>, and <> you want to have returned by separating them with either a comma or a space. +Defines the fields to return for each document. You can explicitly list the stored fields, <>, and <> you want to have returned by separating them with either a comma or a space. wt:: Specifies the Response Writer to be used to format the query response. Defaults to JSON if not specified. @@ -61,18 +61,18 @@ debugQuery:: Click this button to augment the query response with debugging information, including "explain info" for each document returned. This debugging information is intended to be intelligible to the administrator or programmer. dismax:: -Click this button to enable the Dismax query parser. See <> for further information. +Click this button to enable the Dismax query parser. See <> for further information. edismax:: -Click this button to enable the Extended query parser. See <> for further information. +Click this button to enable the Extended query parser. See <> for further information. -hl:: Click this button to enable highlighting in the query response. See <> for more information. +hl:: Click this button to enable highlighting in the query response. See <> for more information. facet:: -Enables faceting, the arrangement of search results into categories based on indexed terms. See <> for more information. +Enables faceting, the arrangement of search results into categories based on indexed terms. See <> for more information. spatial:: -Click to enable using location data for use in spatial or geospatial searches. See <> for more information. +Click to enable using location data for use in spatial or geospatial searches. See <> for more information. spellcheck:: -Click this button to enable the Spellchecker, which provides inline query suggestions based on other, similar, terms. See <> for more information. +Click this button to enable the Spellchecker, which provides inline query suggestions based on other, similar, terms. See <> for more information. diff --git a/solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc b/solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc index 32cd0513dd7..944143fe757 100644 --- a/solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc @@ -57,9 +57,9 @@ Details of each cache are described below. This cache is used by `SolrIndexSearcher` for filters (DocSets) for unordered sets of all documents that match a query. The numeric attributes control the number of entries in the cache. -The most typical way Solr uses the `filterCache` is to cache results of each `fq` search parameter, though there are some other cases as well. Subsequent queries using the same parameter filter query result in cache hits and rapid returns of results. See <> for a detailed discussion of the `fq` parameter. Another Solr feature using this cache is the `filter(...)` syntax in the default Lucene query parser. +The most typical way Solr uses the `filterCache` is to cache results of each `fq` search parameter, though there are some other cases as well. Subsequent queries using the same parameter filter query result in cache hits and rapid returns of results. See <> for a detailed discussion of the `fq` parameter. Another Solr feature using this cache is the `filter(...)` syntax in the default Lucene query parser. -Solr also uses this cache for faceting when the configuration parameter `facet.method` is set to `fc`. For a discussion of faceting, see <>. +Solr also uses this cache for faceting when the configuration parameter `facet.method` is set to `fc`. For a discussion of faceting, see <>. [source,xml] ---- @@ -243,7 +243,7 @@ Good query selection is key with this type of listener. It's best to choose your There are two types of events that can trigger a listener. A `firstSearcher` event occurs when a new searcher is being prepared but there is no current registered searcher to handle requests or to gain auto-warming data from (i.e., on Solr startup). A `newSearcher` event is fired whenever a new searcher is being prepared and there is a current searcher handling requests. -The (commented out) examples below can be found in the `solrconfig.xml` file of the `sample_techproducts_configs` <> included with Solr, and demonstrate using the `solr.QuerySenderListener` class to warm a set of explicit queries: +The (commented out) examples below can be found in the `solrconfig.xml` file of the `sample_techproducts_configs` <> included with Solr, and demonstrate using the `solr.QuerySenderListener` class to warm a set of explicit queries: [source,xml] ---- diff --git a/solr/solr-ref-guide/src/query-syntax-and-parsing.adoc b/solr/solr-ref-guide/src/query-syntax-and-parsing.adoc index c8867318126..4ef0cc1eb46 100644 --- a/solr/solr-ref-guide/src/query-syntax-and-parsing.adoc +++ b/solr/solr-ref-guide/src/query-syntax-and-parsing.adoc @@ -19,13 +19,13 @@ Solr supports several query parsers, offering search application designers great flexibility in controlling how queries are parsed. -This section explains how to specify the query parser to be used. It also describes the syntax and features supported by the main query parsers included with Solr and describes some other parsers that may be useful for particular situations. There are some query parameters common to all Solr parsers; these are discussed in the section <>. +This section explains how to specify the query parser to be used. It also describes the syntax and features supported by the main query parsers included with Solr and describes some other parsers that may be useful for particular situations. There are some query parameters common to all Solr parsers; these are discussed in the section <>. The parsers discussed in this Guide are: -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> The query parser plugins are all subclasses of {solr-javadocs}/core/org/apache/solr/search/QParserPlugin.html[QParserPlugin]. If you have custom parsing needs, you may want to extend that class to create your own query parser. diff --git a/solr/solr-ref-guide/src/realtime-get.adoc b/solr/solr-ref-guide/src/realtime-get.adoc index 46e46ba9775..b9450e688e5 100644 --- a/solr/solr-ref-guide/src/realtime-get.adoc +++ b/solr/solr-ref-guide/src/realtime-get.adoc @@ -29,7 +29,7 @@ Real Time Get relies on the update log feature, which is enabled by default and ---- -Real Time Get requests can be performed using the `/get` handler which exists implicitly in Solr - see <> - it's equivalent to the following configuration: +Real Time Get requests can be performed using the `/get` handler which exists implicitly in Solr - see <> - it's equivalent to the following configuration: [source,xml] ---- diff --git a/solr/solr-ref-guide/src/reindexing.adoc b/solr/solr-ref-guide/src/reindexing.adoc index fc4ddb0e093..e2b2b2ebafa 100644 --- a/solr/solr-ref-guide/src/reindexing.adoc +++ b/solr/solr-ref-guide/src/reindexing.adoc @@ -57,7 +57,7 @@ Changing field properties that affect indexing without reindexing is not recomme ==== Changing Field Analysis -Beyond specific field-level properties, <> are also configured on field types, and are applied at index and query time. +Beyond specific field-level properties, <> are also configured on field types, and are applied at index and query time. If separate analysis chains are defined for query and indexing events for a field and you change _only_ the query-time analysis chain, reindexing is not necessary. @@ -68,7 +68,7 @@ Identifying changes to solrconfig.xml that alter how data is ingested and thus r The parameter `luceneMatchVersion` in solrconfig.xml controls the compatibility of Solr with Lucene. Since this parameter can change the rules for analysis behind the scenes, it's always recommended to reindex when changing it. Usually this is only changed in conjunction with a major upgrade. -If you make a change to Solr's <>, it's generally because you want to change something about how _update requests_ (documents) are _processed_ (indexed). In this case, we recommend that you reindex your documents to implement the changes you've made just as if you had changed the schema. +If you make a change to Solr's <>, it's generally because you want to change something about how _update requests_ (documents) are _processed_ (indexed). In this case, we recommend that you reindex your documents to implement the changes you've made just as if you had changed the schema. Similarly, if you change the `codecFactory` parameter in `solrconfig.xml`, it is again strongly recommended that you plan to reindex your documents to avoid unintended behavior. diff --git a/solr/solr-ref-guide/src/replica-management.adoc b/solr/solr-ref-guide/src/replica-management.adoc index 14dc2647fa5..037bd1ac33b 100644 --- a/solr/solr-ref-guide/src/replica-management.adoc +++ b/solr/solr-ref-guide/src/replica-management.adoc @@ -76,7 +76,7 @@ The number of `tlog` replicas that should be created (optional, defaults to 1 if The number of `pull` replicas that should be created (optional, defaults to 1 if `type` is `pull` otherwise 0). `property._name_=_value_`:: -Set core property _name_ to _value_. See <> for details about supported properties and values. +Set core property _name_ to _value_. See <> for details about supported properties and values. [WARNING] ==== diff --git a/solr/solr-ref-guide/src/replica-placement-plugins.adoc b/solr/solr-ref-guide/src/replica-placement-plugins.adoc index 7850d4c5e01..39369bc1d40 100644 --- a/solr/solr-ref-guide/src/replica-placement-plugins.adoc +++ b/solr/solr-ref-guide/src/replica-placement-plugins.adoc @@ -236,4 +236,4 @@ curl -X POST -H 'Content-type: application/json' -d '{ } }}' http://localhost:8983/api/cluster/plugin ----- \ No newline at end of file +---- diff --git a/solr/solr-ref-guide/src/replication-screen.adoc b/solr/solr-ref-guide/src/replication-screen.adoc index 757f156afb0..a5602662b56 100644 --- a/solr/solr-ref-guide/src/replication-screen.adoc +++ b/solr/solr-ref-guide/src/replication-screen.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -The Replication screen shows you the current replication state for the core you have specified. <> has supplanted much of this functionality, but if you are still using Leader-Follower index replication, you can use this screen to: +The Replication screen shows you the current replication state for the core you have specified. <> has supplanted much of this functionality, but if you are still using Leader-Follower index replication, you can use this screen to: . View the replicatable index state. (on a leader node) . View the current replication status (on a follower node) @@ -25,9 +25,9 @@ The Replication screen shows you the current replication state for the core you .Caution When Using SolrCloud [IMPORTANT] ==== -When using <>, do not attempt to disable replication via this screen. +When using <>, do not attempt to disable replication via this screen. image::images/replication-screen/replication.png[image,width=412,height=250] ==== -More details on how to configure replication is available in the section called <>. +More details on how to configure replication is available in the section called <>. diff --git a/solr/solr-ref-guide/src/request-parameters-api.adoc b/solr/solr-ref-guide/src/request-parameters-api.adoc index 2f26f8da892..5e338c63379 100644 --- a/solr/solr-ref-guide/src/request-parameters-api.adoc +++ b/solr/solr-ref-guide/src/request-parameters-api.adoc @@ -20,7 +20,7 @@ The Request Parameters API allows creating parameter sets, a.k.a. paramsets, tha The parameter sets defined with this API can be used in requests to Solr, or referenced directly in `solrconfig.xml` request handler definitions. -It is really another endpoint of the <> instead of a separate API, and has distinct commands. It does not replace or modify any sections of `solrconfig.xml`, but instead provides another approach to handling parameters used in requests. It behaves in the same way as the Config API, by storing parameters in another file that will be used at runtime. In this case, the parameters are stored in a file named `params.json`. This file is kept in ZooKeeper or in the `conf` directory of a standalone Solr instance. +It is really another endpoint of the <> instead of a separate API, and has distinct commands. It does not replace or modify any sections of `solrconfig.xml`, but instead provides another approach to handling parameters used in requests. It behaves in the same way as the Config API, by storing parameters in another file that will be used at runtime. In this case, the parameters are stored in a file named `params.json`. This file is kept in ZooKeeper or in the `conf` directory of a standalone Solr instance. The settings stored in `params.json` are used at query time to override settings defined in `solrconfig.xml` in some cases as described below. @@ -135,7 +135,7 @@ It will be equivalent to a standard request handler definition such as this one: === Implicit RequestHandlers with the Request Parameters API -Solr ships with many out-of-the-box request handlers that may only be configured via the Request Parameters API, because their configuration is not present in `solrconfig.xml`. See <> for the paramset to use when configuring an implicit request handler. +Solr ships with many out-of-the-box request handlers that may only be configured via the Request Parameters API, because their configuration is not present in `solrconfig.xml`. See <> for the paramset to use when configuring an implicit request handler. === Viewing Expanded Paramsets and Effective Parameters with RequestHandlers diff --git a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc index 72f703896f4..77a1ddf65d2 100644 --- a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc @@ -33,7 +33,7 @@ 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` request handler is defined by default, so a value of "false" will work fine. See the section <> 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 <> for more information. [source,xml] ---- diff --git a/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc b/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc index 0fed06f34b5..c362d34cb3c 100644 --- a/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/requesthandlers-and-searchcomponents-in-solrconfig.adoc @@ -18,15 +18,15 @@ After the `` section of `solrconfig.xml`, request handlers and search components are configured. -A _request handler_ processes requests coming to Solr. These might be query requests, index update requests or specialized interactions such as <>. +A _request handler_ processes requests coming to Solr. These might be query requests, index update requests or specialized interactions such as <>. -Not all handlers are defined explicitly in `solrconfig.xml`, many essential ones are actually defined <>. +Not all handlers are defined explicitly in `solrconfig.xml`, many essential ones are actually defined <>. -Additionally, handlers can be defined - or even overridden - in `configoverlay.json` by using <>. -Finally, independent parameter sets can be also defined by <>. +Additionally, handlers can be defined - or even overridden - in `configoverlay.json` by using <>. +Finally, independent parameter sets can be also defined by <>. They will be stored in `params.json` file and referenced with <<#paramsets-and-useparams,useParams>>. -All of this multi-layered configuration, may be verified via <>. +All of this multi-layered configuration, may be verified via <>. Defining your own config handlers is often a useful way to provide defaults and advanced configuration to support business cases and simplify client API. At the same time, using every single option explained in this guide, will most certainly cause some confusion about which parameter is actually used when. @@ -77,7 +77,7 @@ Notice the URL-encoded space (as +) for the values of `fl` parameter. http://localhost:8983/solr/techproducts/select?q=id:SP2514N&fl=id+name&wt=xml ---- -And here is an example of parameters being sent through the POST form to `/query` Search Handler using <>. +And here is an example of parameters being sent through the POST form to `/query` Search Handler using <>. [source,bash] ---- @@ -163,11 +163,11 @@ these are the only facets they will be able to see counts for; regardless of wha It is also possible to configure defaults for request handlers with a section called `initParams`. These defaults can be used when you want to have common properties that will be used by each separate handler. For example, if you intend to create several request handlers that will all request the same list of fields in the response, you can configure an `initParams` section with your list of fields. -For more information about `initParams`, see the section <>. +For more information about `initParams`, see the section <>. === Paramsets and UseParams If you are expecting to change the parameters often, or if you want define sets of parameters that you can apply on the fly, -you can define them with <> and then invoke them +you can define them with <> and then invoke them by providing one or more in `useParams` setting either in the handler definition itself or as a query parameter. [source,xml] @@ -184,7 +184,7 @@ http://localhost/solr/techproducts/select?useParams=myFacets,myQueries ---- If paramset is called but is not defined, it is ignored. -This allows most <> to call specific paramsets, +This allows most <> to call specific paramsets, that you can define later, as needed. @@ -206,7 +206,7 @@ The following sections are allowed within a Search Handler: All the blocks are optional, especially since parameters can also be provided with `initParams` and `useParams`. -The defaults/appends/invariants blocks were described <<#defaults-appends-and-invariants,higher>> on the page. All the parameters described in the section <> can be defined as parameters for any of the Search Handlers. +The defaults/appends/invariants blocks were described <<#defaults-appends-and-invariants,higher>> on the page. All the parameters described in the section <> can be defined as parameters for any of the Search Handlers. The Search Components blocks are described next, and <> is for fine-tuning of the SolrCloud distributed requests. @@ -222,14 +222,14 @@ As you can see below, what we see as a search experience is mostly a sequence of [cols="20,40,40",options="header"] |=== |Component Name |Class Name |More Information -|query |`solr.QueryComponent` |Described in the section <>. -|facet |`solr.FacetComponent` |Original parameter-based facet component, described in the section <>. -|facet_module |`solr.facet.FacetModule` | JSON Faceting and Analytics module, described in the section <>. -|mlt |`solr.MoreLikeThisComponent` |Described in the section <>. -|highlight |`solr.HighlightComponent` |Described in the section <>. -|stats |`solr.StatsComponent` |Described in the section <>. -|expand |`solr.ExpandComponent` |Described in the section <>. -|terms |`solr.TermsComponent` |Described in the section <>. +|query |`solr.QueryComponent` |Described in the section <>. +|facet |`solr.FacetComponent` |Original parameter-based facet component, described in the section <>. +|facet_module |`solr.facet.FacetModule` | JSON Faceting and Analytics module, described in the section <>. +|mlt |`solr.MoreLikeThisComponent` |Described in the section <>. +|highlight |`solr.HighlightComponent` |Described in the section <>. +|stats |`solr.StatsComponent` |Described in the section <>. +|expand |`solr.ExpandComponent` |Described in the section <>. +|terms |`solr.TermsComponent` |Described in the section <>. |debug |`solr.DebugComponent` |Described in the section on <>. |=== @@ -237,15 +237,15 @@ As you can see below, what we see as a search experience is mostly a sequence of Apart from default components, Solr ships with a number of additional - very useful - components. They do need to defined and referenced in `solrconfig.xml` to be actually used. -* `AnalyticsComponent`, described in the section <>. -* `ClusteringComponent`, described in the section <>. +* `AnalyticsComponent`, described in the section <>. +* `ClusteringComponent`, described in the section <>. * `PhrasesIdentificationComponent`, used to identify & score "phrases" found in the input string, based on shingles in indexed fields, described in the {solr-javadocs}/core/org/apache/solr/handler/component/PhrasesIdentificationComponent.html[PhrasesIdentificationComponent] javadocs. -* `QueryElevationComponent`, described in the section <>. -* `RealTimeGetComponent`, described in the section <>. +* `QueryElevationComponent`, described in the section <>. +* `RealTimeGetComponent`, described in the section <>. * `ResponseLogComponent`, used to record which documents are returned to the user via the Solr log, described in the {solr-javadocs}/core/org/apache/solr/handler/component/ResponseLogComponent.html[ResponseLogComponent] javadocs. -* `SpellCheckComponent`, described in the section <>. -* `SuggestComponent`, described in the section <>. -* `TermVectorComponent`, described in the section <>. +* `SpellCheckComponent`, described in the section <>. +* `SuggestComponent`, described in the section <>. +* `TermVectorComponent`, described in the section <>. Some third party components are also linked from https://solr.cool/ website. @@ -315,10 +315,10 @@ If you need to define additional Update Request Handler, the syntax is: ---- -The full details are covered in the section <>. +The full details are covered in the section <>. Similar to Search Components for Search Handlers, Solr has document-preprocessing plugins for Update Request Handlers, -called <>, +called <>, which also allow for default and custom configuration chains. -Note: Do not confuse Update Request Handlers with <> section also defined in `solrconfig.xml`. \ No newline at end of file +Note: Do not confuse Update Request Handlers with <> section also defined in `solrconfig.xml`. diff --git a/solr/solr-ref-guide/src/resource-loading.adoc b/solr/solr-ref-guide/src/resource-loading.adoc index c1fb6327568..e0e457b7e47 100644 --- a/solr/solr-ref-guide/src/resource-loading.adoc +++ b/solr/solr-ref-guide/src/resource-loading.adoc @@ -19,17 +19,17 @@ Solr components can be configured using *resources*: data stored in external files that may be referred to in a location-independent fashion. -Examples of resources include: files needed by schema components, e.g., a stopword list for <>; and machine-learned models for <>. +Examples of resources include: files needed by schema components, e.g., a stopword list for <>; and machine-learned models for <>. _Resources are typically resolved from the configSet_ but there are other options too. Solr's resources are generally only loaded initially when the Solr collection or Solr core is loaded. After you update a resource, you'll typically need to _reload_ the affected collections (SolrCloud) or the cores (standalone Solr). Restarting all affected Solr nodes also works. -<> can be manipulated via APIs and do not need an explicit reload. +<> can be manipulated via APIs and do not need an explicit reload. == Resources in Configsets -<> are the directories containing solrconfig.xml, the schema, and resources referenced by them. +<> are the directories containing solrconfig.xml, the schema, and resources referenced by them. In SolrCloud they are in ZooKeeper whereas in standalone they are on the file system. In either mode, configSets might be shared or might be dedicated to a configSet. Prefer to put resources here. diff --git a/solr/solr-ref-guide/src/response-writers.adoc b/solr/solr-ref-guide/src/response-writers.adoc index e550a9925bb..f472e4ba94f 100644 --- a/solr/solr-ref-guide/src/response-writers.adoc +++ b/solr/solr-ref-guide/src/response-writers.adoc @@ -170,7 +170,7 @@ The Content-Type of the response is set according to the `` statemen === XSLT Configuration -The example below, from the `sample_techproducts_configs` <> in the Solr distribution, shows how the XSLT Response Writer is configured. +The example below, from the `sample_techproducts_configs` <> in the Solr distribution, shows how the XSLT Response Writer is configured. [source,xml] ---- @@ -188,7 +188,7 @@ A value of 5 for `xsltCacheLifetimeSeconds` is good for development, to see XSLT == Binary Response Writer -This is a custom binary format used by Solr for inter-node communication as well as client-server communication. SolrJ uses this as the default for indexing as well as querying. See <> for more details. +This is a custom binary format used by Solr for inter-node communication as well as client-server communication. SolrJ uses this as the default for indexing as well as querying. See <> for more details. == GeoJSON Response Writer @@ -256,7 +256,7 @@ rsp['response']['docs'].each { |doc| puts 'name field = ' + doc['name'\] } The CSV response writer returns a list of documents in comma-separated values (CSV) format. Other information that would normally be included in a response, such as facet information, is excluded. -The CSV response writer supports multi-valued fields, as well as <>, and the output of this CSV format is compatible with Solr's <>. +The CSV response writer supports multi-valued fields, as well as <>, and the output of this CSV format is compatible with Solr's <>. === CSV Parameters diff --git a/solr/solr-ref-guide/src/result-clustering.adoc b/solr/solr-ref-guide/src/result-clustering.adoc index 9158bbdb12b..1563a0968a3 100644 --- a/solr/solr-ref-guide/src/result-clustering.adoc +++ b/solr/solr-ref-guide/src/result-clustering.adoc @@ -31,7 +31,7 @@ Clusters discovered for a given query can be perceived as _dynamic facets_. This image::images/result-clustering/carrot2.png[image,width=900] -The query issued to the system was _Apache Solr_. It seems clear that faceting could not yield a similar set of groups, although the goals of both techniques are similar—to let the user explore the set of search results and either rephrase the query or narrow the focus to a subset of current documents. Clustering is also similar to <> in that it can help to look deeper into search results, beyond the top few hits. +The query issued to the system was _Apache Solr_. It seems clear that faceting could not yield a similar set of groups, although the goals of both techniques are similar—to let the user explore the set of search results and either rephrase the query or narrow the focus to a subset of current documents. Clustering is also similar to <> in that it can help to look deeper into search results, beyond the top few hits. == Configuration Quick Starter diff --git a/solr/solr-ref-guide/src/result-grouping.adoc b/solr/solr-ref-guide/src/result-grouping.adoc index a687b781e4d..fb811486443 100644 --- a/solr/solr-ref-guide/src/result-grouping.adoc +++ b/solr/solr-ref-guide/src/result-grouping.adoc @@ -23,10 +23,10 @@ For example, if you searched for "DVD" on an electronic retailer's e-commerce si .Prefer Collapse & Expand instead [NOTE] ==== -Solr's <> feature is newer and mostly overlaps with Result Grouping. There are features unique to both, and they have different performance characteristics. That said, in most cases Collapse and Expand is preferable to Result Grouping. +Solr's <> feature is newer and mostly overlaps with Result Grouping. There are features unique to both, and they have different performance characteristics. That said, in most cases Collapse and Expand is preferable to Result Grouping. ==== -Result Grouping is separate from <>. Though it is conceptually similar, faceting returns all relevant results and allows the user to refine the results based on the facet category. For example, if you search for "shoes" on a footwear retailer's e-commerce site, Solr would return all results for that query term, along with selectable facets such as "size," "color," "brand," and so on. +Result Grouping is separate from <>. Though it is conceptually similar, faceting returns all relevant results and allows the user to refine the results based on the facet category. For example, if you search for "shoes" on a footwear retailer's e-commerce site, Solr would return all results for that query term, along with selectable facets such as "size," "color," "brand," and so on. You can however combine grouping with faceting. Grouped faceting supports `facet.field` and `facet.range` but currently doesn't support date and pivot faceting. The facet counts are computed based on the first `group.field` parameter, and other `group.field` parameters are ignored. @@ -264,7 +264,7 @@ In this case, Solr found five matches for "memory," but only returns four result == Distributed Result Grouping Caveats -Grouping is supported for <>, with some caveats: +Grouping is supported for <>, with some caveats: * Currently `group.func` is is not supported in any distributed searches -* `group.ngroups` and `group.facet` require that all documents in each group must be co-located on the same shard in order for accurate counts to be returned. <> can be a useful solution in many situations. +* `group.ngroups` and `group.facet` require that all documents in each group must be co-located on the same shard in order for accurate counts to be returned. <> can be a useful solution in many situations. diff --git a/solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc b/solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc index fc00166a41e..7c709780fa5 100644 --- a/solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc +++ b/solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc @@ -33,7 +33,7 @@ In Rule-Based Authorization, administrators define a series of roles based on th === Users -The users that RBAP sees come from whatever authentication plugin has been configured. RBAP is compatible with all of the authentication plugins that Solr ships with out of the box. It is also compatible with any custom authentication plugins users might write, provided that the plugin sets a user principal on the HttpServletRequest it receives. The user value seen by RBAP in each case depends on the authentication plugin being used: the Kerberos principal if the <> is being used, the "sub" JWT claim if the <> is being used, etc. +The users that RBAP sees come from whatever authentication plugin has been configured. RBAP is compatible with all of the authentication plugins that Solr ships with out of the box. It is also compatible with any custom authentication plugins users might write, provided that the plugin sets a user principal on the HttpServletRequest it receives. The user value seen by RBAP in each case depends on the authentication plugin being used: the Kerberos principal if the <> is being used, the "sub" JWT claim if the <> is being used, etc. === Roles @@ -89,7 +89,7 @@ This setting is optional and defaults to `false` if unset. === Example for RuleBasedAuthorizationPlugin and BasicAuth -This example `security.json` shows how the <> can work with the `RuleBasedAuthorizationPlugin` plugin: +This example `security.json` shows how the <> can work with the `RuleBasedAuthorizationPlugin` plugin: [source,json] ---- @@ -126,7 +126,7 @@ Altogether, this example carves out two restricted areas. Only `admin-user` can === Example for External Role RuleBasedAuthorizationPlugin with JWT auth -This example `security.json` shows how the <>, which pulls user and user roles from JWT claims, can work with the `ExternalRoleRuleBasedAuthorizationPlugin` plugin: +This example `security.json` shows how the <>, which pulls user and user roles from JWT claims, can work with the `ExternalRoleRuleBasedAuthorizationPlugin` plugin: [source,json] ---- @@ -208,15 +208,15 @@ The predefined permission names (and their effects) are: * *security-edit:* this permission is allowed to edit the security configuration, meaning any update action that modifies `security.json` through the APIs will be allowed. * *security-read*: this permission is allowed to read the security configuration, meaning any action that reads `security.json` settings through the APIs will be allowed. -* *schema-edit*: this permission is allowed to edit a collection's schema using the <>. Note that this allows schema edit permissions for _all_ collections. If edit permissions should only be applied to specific collections, a custom permission would need to be created. -* *schema-read*: this permission is allowed to read a collection's schema using the <>. Note that this allows schema read permissions for _all_ collections. If read permissions should only be applied to specific collections, a custom permission would need to be created. -* *config-edit*: this permission is allowed to edit a collection's configuration using the <>, the <>, and other APIs which modify `configoverlay.json`. Note that this allows configuration edit permissions for _all_ collections. If edit permissions should only be applied to specific collections, a custom permission would need to be created. -* *config-read*: this permission is allowed to read a collection's configuration using the <>, the <>, and other APIs which modify `configoverlay.json`. Note that this allows configuration read permissions for _all_ collections. If read permissions should only be applied to specific collections, a custom permission would need to be created. +* *schema-edit*: this permission is allowed to edit a collection's schema using the <>. Note that this allows schema edit permissions for _all_ collections. If edit permissions should only be applied to specific collections, a custom permission would need to be created. +* *schema-read*: this permission is allowed to read a collection's schema using the <>. Note that this allows schema read permissions for _all_ collections. If read permissions should only be applied to specific collections, a custom permission would need to be created. +* *config-edit*: this permission is allowed to edit a collection's configuration using the <>, the <>, and other APIs which modify `configoverlay.json`. Note that this allows configuration edit permissions for _all_ collections. If edit permissions should only be applied to specific collections, a custom permission would need to be created. +* *config-read*: this permission is allowed to read a collection's configuration using the <>, the <>, and other APIs which modify `configoverlay.json`. Note that this allows configuration read permissions for _all_ collections. If read permissions should only be applied to specific collections, a custom permission would need to be created. * *metrics-read*: this permission allows access to Solr's <> * *metrics-history-read*: this permission allows access to Solr's <>, which provides long-term history for a select set of key Solr metrics. * *core-admin-edit*: Core admin commands that can mutate the system state. * *core-admin-read*: Read operations on the core admin API -* *collection-admin-edit*: this permission is allowed to edit a collection's configuration using the <>. Note that this allows configuration edit permissions for _all_ collections. If edit permissions should only be applied to specific collections, a custom permission would need to be created. Specifically, the following actions of the Collections API would be allowed: +* *collection-admin-edit*: this permission is allowed to edit a collection's configuration using the <>. Note that this allows configuration edit permissions for _all_ collections. If edit permissions should only be applied to specific collections, a custom permission would need to be created. Specifically, the following actions of the Collections API would be allowed: ** CREATE ** RELOAD ** SPLITSHARD @@ -235,7 +235,7 @@ The predefined permission names (and their effects) are: ** DELETEREPLICAPROP ** BALANCESHARDUNIQUE ** REBALANCELEADERS -* *collection-admin-read*: this permission is allowed to read a collection's configuration using the <>. Note that this allows configuration read permissions for _all_ collections. If read permissions should only be applied to specific collections, a custom permission would need to be created. Specifically, the following actions of the Collections API would be allowed: +* *collection-admin-read*: this permission is allowed to read a collection's configuration using the <>. Note that this allows configuration read permissions for _all_ collections. If read permissions should only be applied to specific collections, a custom permission would need to be created. Specifically, the following actions of the Collections API would be allowed: ** LIST ** OVERSEERSTATUS ** CLUSTERSTATUS diff --git a/solr/solr-ref-guide/src/running-your-analyzer.adoc b/solr/solr-ref-guide/src/running-your-analyzer.adoc index bcbfe531dd9..092b4b96776 100644 --- a/solr/solr-ref-guide/src/running-your-analyzer.adoc +++ b/solr/solr-ref-guide/src/running-your-analyzer.adoc @@ -16,11 +16,11 @@ // specific language governing permissions and limitations // under the License. -Once you've <>, and specified the analysis steps that you want applied to it, you should test it out to make sure that it behaves the way you expect it to. +Once you've <>, and specified the analysis steps that you want applied to it, you should test it out to make sure that it behaves the way you expect it to. -Luckily, there is a very handy page in the Solr <> that lets you do just that. You can invoke the analyzer for any text field, provide sample input, and display the resulting token stream. +Luckily, there is a very handy page in the Solr <> that lets you do just that. You can invoke the analyzer for any text field, provide sample input, and display the resulting token stream. -For example, let's look at some of the "Text" field types available in the `bin/solr -e techproducts` example configuration, and use the <> (`\http://localhost:8983/solr/#/techproducts/analysis`) to compare how the tokens produced at index time for the sentence "Running an Analyzer" match up with a slightly different query text of "run my analyzer" +For example, let's look at some of the "Text" field types available in the `bin/solr -e techproducts` example configuration, and use the <> (`\http://localhost:8983/solr/#/techproducts/analysis`) to compare how the tokens produced at index time for the sentence "Running an Analyzer" match up with a slightly different query text of "run my analyzer" We can begin with "```text_ws```" - one of the most simplified Text field types available: diff --git a/solr/solr-ref-guide/src/schema-api.adoc b/solr/solr-ref-guide/src/schema-api.adoc index 85d8d9df062..450c9c38f82 100644 --- a/solr/solr-ref-guide/src/schema-api.adoc +++ b/solr/solr-ref-guide/src/schema-api.adoc @@ -18,7 +18,7 @@ The Schema API allows you to use an HTTP API to manage many of the elements of your schema. -The Schema API utilizes the ManagedIndexSchemaFactory class, which is the default schema factory in modern Solr versions. See the section <> for more information about choosing a schema factory for your index. +The Schema API utilizes the ManagedIndexSchemaFactory class, which is the default schema factory in modern Solr versions. See the section <> for more information about choosing a schema factory for your index. This API provides read and write access to the Solr schema for each collection (or core, when using standalone Solr). Read access to all schema elements is supported. Fields, dynamic fields, field types and copyField rules may be added, removed or replaced. Future Solr releases will extend write access to allow more schema elements to be modified. @@ -41,7 +41,7 @@ If you modify your schema, you will likely need to reindex all documents. If you Modifying your schema will never modify any documents that are already indexed. You must reindex documents in order to apply schema changes to them. Queries and updates made after the change may encounter errors that were not present before the change. Completely deleting the index and rebuilding it is usually the only option to fix such errors. -See the section <> for more information about reindexing. +See the section <> for more information about reindexing. ==== //// @@ -96,7 +96,7 @@ When modifying the schema with the API, a core reload will automatically occur i The `add-field` command adds a new field definition to your schema. If a field with the same name exists an error is thrown. -All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <>. +All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <>. For example, to define a new stored field named "sell_by", of type "pdate", you would POST the following request: @@ -166,7 +166,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '{ The `replace-field` command replaces a field's definition. Note that you must supply the full definition for a field - this command will *not* partially modify a field's definition. If the field does not exist in the schema an error is thrown. -All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <>. +All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <>. For example, to replace the definition of an existing field "sell_by", to make it be of type "date" and to not be stored, you would POST the following request: @@ -205,7 +205,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '{ The `add-dynamic-field` command adds a new dynamic field rule to your schema. -All of the properties available when editing `schema.xml` can be passed with the POST request. The section <> has details on all of the attributes that can be defined for a dynamic field rule. +All of the properties available when editing `schema.xml` can be passed with the POST request. The section <> has details on all of the attributes that can be defined for a dynamic field rule. For example, to create a new dynamic field rule where all incoming fields ending with "_s" would be stored and have field type "string", you can POST a request like this: @@ -275,7 +275,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '{ The `replace-dynamic-field` command replaces a dynamic field rule in your schema. Note that you must supply the full definition for a dynamic field rule - this command will *not* partially modify a dynamic field rule's definition. If the dynamic field rule does not exist in the schema an error is thrown. -All of the properties available when editing `schema.xml` can be passed with the POST request. The section <> has details on all of the attributes that can be defined for a dynamic field rule. +All of the properties available when editing `schema.xml` can be passed with the POST request. The section <> has details on all of the attributes that can be defined for a dynamic field rule. For example, to replace the definition of the "*_s" dynamic field rule with one where the field type is "text_general" and it's not stored, you can POST a request like this: @@ -314,7 +314,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '{ The `add-field-type` command adds a new field type to your schema. -All of the field type properties available when editing `schema.xml` by hand are available for use in a POST request. The structure of the command is a JSON mapping of the standard field type definition, including the name, class, index and query analyzer definitions, etc. Details of all of the available options are described in the section <>. +All of the field type properties available when editing `schema.xml` by hand are available for use in a POST request. The structure of the command is a JSON mapping of the standard field type definition, including the name, class, index and query analyzer definitions, etc. Details of all of the available options are described in the section <>. For example, to create a new field type named "myNewTxtField", you can POST a request as follows: @@ -427,7 +427,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '{ The `replace-field-type` command replaces a field type in your schema. Note that you must supply the full definition for a field type - this command will *not* partially modify a field type's definition. If the field type does not exist in the schema an error is thrown. -All of the field type properties available when editing `schema.xml` by hand are available for use in a POST request. The structure of the command is a JSON mapping of the standard field type definition, including the name, class, index and query analyzer definitions, etc. Details of all of the available options are described in the section <>. +All of the field type properties available when editing `schema.xml` by hand are available for use in a POST request. The structure of the command is a JSON mapping of the standard field type definition, including the name, class, index and query analyzer definitions, etc. Details of all of the available options are described in the section <>. For example, to replace the definition of a field type named "myNewTxtField", you can make a POST request as follows: @@ -481,7 +481,7 @@ The source field. This parameter is required. A field or an array of fields to which the source field will be copied. This parameter is required. `maxChars`:: -The upper limit for the number of characters to be copied. The section <> has more details. +The upper limit for the number of characters to be copied. The section <> has more details. For example, to define a rule to copy the field "shelf" to the "location" and "catchall" fields, you would POST the following request: @@ -840,7 +840,7 @@ If `true`, all default field properties from each field's field type will be inc The output will include each field and any defined configuration for each field. The defined configuration can vary for each field, but will minimally include the field `name`, the `type`, if it is `indexed` and if it is `stored`. -If `multiValued` is defined as either true or false (most likely true), that will also be shown. See the section <> for more information about each parameter. +If `multiValued` is defined as either true or false (most likely true), that will also be shown. See the section <> for more information about each parameter. ==== List Fields Examples @@ -913,7 +913,7 @@ If `true`, all default field properties from each dynamic field's field type wil ==== List Dynamic Field Response -The output will include each dynamic field rule and the defined configuration for each rule. The defined configuration can vary for each rule, but will minimally include the dynamic field `name`, the `type`, if it is `indexed` and if it is `stored`. See the section <> for more information about each parameter. +The output will include each dynamic field rule and the defined configuration for each rule. The defined configuration can vary for each rule, but will minimally include the dynamic field `name`, the `type`, if it is `indexed` and if it is `stored`. See the section <> for more information about each parameter. ==== List Dynamic Field Examples @@ -996,7 +996,7 @@ If `true`, all default field properties from each dynamic field's field type wil ==== List Field Type Response -The output will include each field type and any defined configuration for the type. The defined configuration can vary for each type, but will minimally include the field type `name` and the `class`. If query or index analyzers, tokenizers, or filters are defined, those will also be shown with other defined parameters. See the section <> for more information about how to configure various types of fields. +The output will include each field type and any defined configuration for the type. The defined configuration can vary for each type, but will minimally include the field type `name` and the `class`. If query or index analyzers, tokenizers, or filters are defined, those will also be shown with other defined parameters. See the section <> for more information about how to configure various types of fields. ==== List Field Type Examples @@ -1083,7 +1083,7 @@ Comma- or space-separated list of one or more copyField destination fields to in ==== List Copy Field Response -The output will include the `source` and `dest` (destination) of each copy field rule defined in `schema.xml`. For more information about copying fields, see the section <>. +The output will include the `source` and `dest` (destination) of each copy field rule defined in `schema.xml`. For more information about copying fields, see the section <>. ==== List Copy Field Examples @@ -1288,4 +1288,4 @@ curl http://localhost:8983/solr/gettingstarted/schema/similarity == Manage Resource Data -The <> REST API provides a mechanism for any Solr plugin to expose resources that should support CRUD (Create, Read, Update, Delete) operations. Depending on what Field Types and Analyzers are configured in your Schema, additional `/schema/` REST API paths may exist. See the <> section for more information and examples. +The <> REST API provides a mechanism for any Solr plugin to expose resources that should support CRUD (Create, Read, Update, Delete) operations. Depending on what Field Types and Analyzers are configured in your Schema, additional `/schema/` REST API paths may exist. See the <> section for more information and examples. diff --git a/solr/solr-ref-guide/src/schema-browser-screen.adoc b/solr/solr-ref-guide/src/schema-browser-screen.adoc index 5cd2fcf1b5b..69b6c4eb379 100644 --- a/solr/solr-ref-guide/src/schema-browser-screen.adoc +++ b/solr/solr-ref-guide/src/schema-browser-screen.adoc @@ -23,15 +23,15 @@ If you have accessed this window from the Analysis screen, it will be opened to .Schema Browser Screen image::images/schema-browser-screen/schema_browser_terms.png[image,height=400] -The screen provides a great deal of useful information about each particular field and fieldtype in the Schema, and provides a quick UI for adding fields or fieldtypes using the <> (if enabled). In the example above, we have chosen the `cat` field. On the left side of the main view window, we see the field name, that it is copied to the `\_text_` (because of a copyField rule) and that it use the `strings` fieldtype. Click on one of those field or fieldtype names, and you can see the corresponding definitions. +The screen provides a great deal of useful information about each particular field and fieldtype in the Schema, and provides a quick UI for adding fields or fieldtypes using the <> (if enabled). In the example above, we have chosen the `cat` field. On the left side of the main view window, we see the field name, that it is copied to the `\_text_` (because of a copyField rule) and that it use the `strings` fieldtype. Click on one of those field or fieldtype names, and you can see the corresponding definitions. -In the right part of the main view, we see the specific properties of how the `cat` field is defined – either explicitly or implicitly via its fieldtype, as well as how many documents have populated this field. Then we see the analyzer used for indexing and query processing. Click the icon to the left of either of those, and you'll see the definitions for the tokenizers and/or filters that are used. The output of these processes is the information you see when testing how content is handled for a particular field with the <>. +In the right part of the main view, we see the specific properties of how the `cat` field is defined – either explicitly or implicitly via its fieldtype, as well as how many documents have populated this field. Then we see the analyzer used for indexing and query processing. Click the icon to the left of either of those, and you'll see the definitions for the tokenizers and/or filters that are used. The output of these processes is the information you see when testing how content is handled for a particular field with the <>. -Under the analyzer information is a button to *Load Term Info*. Clicking that button will show the top _N_ terms that are in a sample shard for that field, as well as a histogram showing the number of terms with various frequencies. Click on a term, and you will be taken to the <> to see the results of a query of that term in that field. If you want to always see the term information for a field, choose *Autoload* and it will always appear when there are terms for a field. A histogram shows the number of terms with a given frequency in the field. +Under the analyzer information is a button to *Load Term Info*. Clicking that button will show the top _N_ terms that are in a sample shard for that field, as well as a histogram showing the number of terms with various frequencies. Click on a term, and you will be taken to the <> to see the results of a query of that term in that field. If you want to always see the term information for a field, choose *Autoload* and it will always appear when there are terms for a field. A histogram shows the number of terms with a given frequency in the field. [IMPORTANT] ==== -Term Information is loaded from single arbitrarily selected core from the collection, to provide a representative sample for the collection. Full <> query results are needed to see precise term counts across the entire collection. +Term Information is loaded from single arbitrarily selected core from the collection, to provide a representative sample for the collection. Full <> query results are needed to see precise term counts across the entire collection. ==== -For programmatic access to the underlying information in this screen please reference the <> +For programmatic access to the underlying information in this screen please reference the <> diff --git a/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc b/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc index cb649f7222a..4a9d242be7e 100644 --- a/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc @@ -16,15 +16,15 @@ // specific language governing permissions and limitations // under the License. -Solr's <> enables remote clients to access <> information, and make schema modifications, through a REST interface. +Solr's <> enables remote clients to access <> information, and make schema modifications, through a REST interface. -Other features such as Solr's <> also work via schema modifications made programatically at run time. +Other features such as Solr's <> also work via schema modifications made programatically at run time. [IMPORTANT] ==== Using the Managed Schema is required to be able to use the Schema API to modify your schema. However, using Managed Schema does not by itself mean you are also using Solr in Schemaless Mode (or "schema guessing" mode). -Schemaless mode requires enabling the Managed Schema if it is not already, but full schema guessing requires additional configuration as described in the section <>. +Schemaless mode requires enabling the Managed Schema if it is not already, but full schema guessing requires additional configuration as described in the section <>. ==== While the "read" features of the Schema API are supported for all schema types, support for making schema modifications programatically depends on the `` in use. @@ -49,7 +49,7 @@ If you wish to explicitly configure `ManagedIndexSchemaFactory` the following op * `mutable` - controls whether changes may be made to the Schema data. This must be set to *true* to allow edits to be made with the Schema API. * `managedSchemaResourceName` is an optional parameter that defaults to "managed-schema", and defines a new name for the schema file that can be anything other than "`schema.xml`". -With the default configuration shown above, you can use the <> to modify the schema as much as you want, and then later change the value of `mutable` to *false* if you wish to "lock" the schema in place and prevent future changes. +With the default configuration shown above, you can use the <> to modify the schema as much as you want, and then later change the value of `mutable` to *false* if you wish to "lock" the schema in place and prevent future changes. == Classic schema.xml @@ -71,7 +71,7 @@ Once Solr is restarted and it detects that a `schema.xml` file exists, but the ` ---- -You are now free to use the <> as much as you want to make changes, and remove the `schema.xml.bak`. +You are now free to use the <> as much as you want to make changes, and remove the `schema.xml.bak`. === Switching from Managed Schema to Manually Edited schema.xml @@ -87,5 +87,5 @@ If you are using SolrCloud, you may need to modify the files via ZooKeeper. The [TIP] ==== -To have full control over your `schema.xml` file, you may also want to disable schema guessing, which allows unknown fields to be added to the schema during indexing. The properties that enable this feature are discussed in the section <>. +To have full control over your `schema.xml` file, you may also want to disable schema guessing, which allows unknown fields to be added to the schema during indexing. The properties that enable this feature are discussed in the section <>. ==== diff --git a/solr/solr-ref-guide/src/schemaless-mode.adoc b/solr/solr-ref-guide/src/schemaless-mode.adoc index 4a35287dbd6..1c60249612e 100644 --- a/solr/solr-ref-guide/src/schemaless-mode.adoc +++ b/solr/solr-ref-guide/src/schemaless-mode.adoc @@ -20,13 +20,13 @@ Schemaless Mode is a set of Solr features that, when used together, allow users These Solr features, all controlled via `solrconfig.xml`, are: -. Managed schema: Schema modifications are made at runtime through Solr APIs, which requires the use of a `schemaFactory` that supports these changes. See the section <> for more details. +. Managed schema: Schema modifications are made at runtime through Solr APIs, which requires the use of a `schemaFactory` that supports these changes. See the section <> for more details. . Field value class guessing: Previously unseen fields are run through a cascading set of value-based parsers, which guess the Java class of field values - parsers for Boolean, Integer, Long, Float, Double, and Date are currently available. -. Automatic schema field addition, based on field value class(es): Previously unseen fields are added to the schema, based on field value Java classes, which are mapped to schema field types - see <>. +. Automatic schema field addition, based on field value class(es): Previously unseen fields are added to the schema, based on field value Java classes, which are mapped to schema field types - see <>. == Using the Schemaless Example -The three features of schemaless mode are pre-configured in the `_default` <> in the Solr distribution. To start an example instance of Solr using these configs, run the following command: +The three features of schemaless mode are pre-configured in the `_default` <> in the Solr distribution. To start an example instance of Solr using these configs, run the following command: [source,bash] ---- @@ -35,7 +35,7 @@ bin/solr start -e schemaless This will launch a single Solr server, and automatically create a collection (named "```gettingstarted```") that contains only three fields in the initial schema: `id`, `\_version_`, and `\_text_`. -You can use the `/schema/fields` <> to confirm this: `curl \http://localhost:8983/solr/gettingstarted/schema/fields` will output: +You can use the `/schema/fields` <> to confirm this: `curl \http://localhost:8983/solr/gettingstarted/schema/fields` will output: [source,json] ---- @@ -70,9 +70,9 @@ As described above, there are three configuration elements that need to be in pl === Enable Managed Schema -As described in the section <>, Managed Schema support is enabled by default, unless your configuration specifies that `ClassicIndexSchemaFactory` should be used. +As described in the section <>, Managed Schema support is enabled by default, unless your configuration specifies that `ClassicIndexSchemaFactory` should be used. -You can configure the `ManagedIndexSchemaFactory` (and control the resource file used, or disable future modifications) by adding an explicit `` like the one below, please see <> for more details on the options available. +You can configure the `ManagedIndexSchemaFactory` (and control the resource file used, or disable future modifications) by adding an explicit `` like the one below, please see <> for more details on the options available. [source,xml] ---- @@ -84,7 +84,7 @@ You can configure the `ManagedIndexSchemaFactory` (and control the resource file === Enable Field Class Guessing -In Solr, an <> defines a chain of plugins that are applied to documents before or while they are indexed. +In Solr, an <> defines a chain of plugins that are applied to documents before or while they are indexed. The field guessing aspect of Solr's schemaless mode uses a specially-defined UpdateRequestProcessorChain that allows Solr to guess field types. You can also define the default field type classes to use. @@ -180,7 +180,7 @@ Once the UpdateRequestProcessorChain has been defined, you must instruct your Up There are two ways to do this. The update chain shown above has a `default=true` attribute which will use it for any update handler. -An alternative, more explicit way is to use <> to set the defaults on all `/update` request handlers: +An alternative, more explicit way is to use <> to set the defaults on all `/update` request handlers: [source,xml] ---- @@ -280,9 +280,9 @@ In addition string versions of the text fields are indexed, using copyFields to .You Can Still Be Explicit [TIP] ==== -Even if you want to use schemaless mode for most fields, you can still use the <> to pre-emptively create some fields, with explicit types, before you index documents that use them. +Even if you want to use schemaless mode for most fields, you can still use the <> to pre-emptively create some fields, with explicit types, before you index documents that use them. -Internally, the Schema API and the Schemaless Update Processors both use the same <> functionality. +Internally, the Schema API and the Schemaless Update Processors both use the same <> functionality. Also, if you do not need the `*_str` version of a text field, you can simply remove the `copyField` definition from the auto-generated schema and it will not be re-added since the original field is now defined. ==== diff --git a/solr/solr-ref-guide/src/search-sample.adoc b/solr/solr-ref-guide/src/search-sample.adoc index 4ef07b066f1..7834e1d763a 100644 --- a/solr/solr-ref-guide/src/search-sample.adoc +++ b/solr/solr-ref-guide/src/search-sample.adoc @@ -76,8 +76,8 @@ These larger samples can be used to build reliable statistical models that descr The examples below demonstrate univariate and bivariate scatter plots of random samples. Statistical modeling with random samples -is covered in the <>, <>, <>, <>, -and <> sections. +is covered in the <>, <>, <>, <>, +and <> sections. === Univariate Scatter Plots @@ -153,7 +153,7 @@ image::images/math-expressions/stats.png[] The `facet` function performs single and multi-dimension aggregations that behave in a similar manner to SQL group by aggregations. Under the covers the `facet` function pushes down the aggregations to Solr's -<> for fast distributed execution. +<> for fast distributed execution. The example below performs a single dimension aggregation from the nyc311 (NYC complaints) dataset. @@ -254,7 +254,7 @@ image::images/math-expressions/sterms.png[] === nodes The `nodes` function performs aggregations of nodes during a breadth first search of a graph. -This function is covered in detail in the section <>. +This function is covered in detail in the section <>. In this example the focus will be on finding correlated nodes in a time series graph using the `nodes` expressions. diff --git a/solr/solr-ref-guide/src/searching-nested-documents.adoc b/solr/solr-ref-guide/src/searching-nested-documents.adoc index a004be23ab2..16b4da722e0 100644 --- a/solr/solr-ref-guide/src/searching-nested-documents.adoc +++ b/solr/solr-ref-guide/src/searching-nested-documents.adoc @@ -19,7 +19,7 @@ This section exposes potential techniques which can be used for searching deeply nested documents, show casing how more complex queries can be constructed using some of Solr's query parsers and Doc Transformers. These features require `\_root_` and `\_nest_path_` to be declared in the schema. + -Please refer to the <> +Please refer to the <> section for more details about schema and index configuration. [NOTE] diff --git a/solr/solr-ref-guide/src/searching.adoc b/solr/solr-ref-guide/src/searching.adoc index 4298548398a..5fb71be77c1 100644 --- a/solr/solr-ref-guide/src/searching.adoc +++ b/solr/solr-ref-guide/src/searching.adoc @@ -48,41 +48,41 @@ This section describes how Solr works with search requests. It covers the following topics: -* <>: An introduction to searching with Solr. -* <>: Conceptual information about understanding relevance in search results. -* <>: A brief conceptual overview of query syntax and parsing. It also contains the following sub-sections: -** <>: No matter the query parser, there are several parameters that are common to all of them. -** <>: Detailed information about the standard Lucene query parser. -** <>: Detailed information about Solr's DisMax query parser. -** <>: Detailed information about Solr's Extended DisMax (eDisMax) Query Parser. -** <>: Detailed information about parameters for generating relevancy scores using values from one or more numeric fields. -** <>: How to add local arguments to queries. -** <>: More parsers designed for use in specific situations. -* <>: Overview of Solr's JSON Request API. -** <>: Detailed information about a simple yet powerful query language for JSON Request API. +* <>: An introduction to searching with Solr. +* <>: Conceptual information about understanding relevance in search results. +* <>: A brief conceptual overview of query syntax and parsing. It also contains the following sub-sections: +** <>: No matter the query parser, there are several parameters that are common to all of them. +** <>: Detailed information about the standard Lucene query parser. +** <>: Detailed information about Solr's DisMax query parser. +** <>: Detailed information about Solr's Extended DisMax (eDisMax) Query Parser. +** <>: Detailed information about parameters for generating relevancy scores using values from one or more numeric fields. +** <>: How to add local arguments to queries. +** <>: More parsers designed for use in specific situations. +* <>: Overview of Solr's JSON Request API. +** <>: Detailed information about a simple yet powerful query language for JSON Request API. * <>: Overview of Solr's JSON Facet API. -* <>: Detailed information about categorizing search results based on indexed terms. -* <>: Detailed information about Solr's highlighting capabilities, including multiple underlying highlighter implementations. -* <>: Detailed information about Solr's spelling checker. -* <>: Detailed information about re-ranking top scoring documents from simple queries using more complex scores. -** <>: How to use LTR to run machine learned ranking models in Solr. +* <>: Detailed information about categorizing search results based on indexed terms. +* <>: Detailed information about Solr's highlighting capabilities, including multiple underlying highlighter implementations. +* <>: Detailed information about Solr's spelling checker. +* <>: Detailed information about re-ranking top scoring documents from simple queries using more complex scores. +** <>: How to use LTR to run machine learned ranking models in Solr. -* <>: Detailed information about using `DocTransformers` to add computed information to individual documents -* <>: Detailed information about constructing nested and hierarchical queries. -* <>: Detailed information about Solr's powerful autosuggest component. -* <>: Detailed information about Solr's similar results query component. -* <>: Detailed information about fetching paginated results for display in a UI, or for fetching all documents matching a query. -* <>: Detailed information about grouping results based on common field values. -* <>: Detailed information about grouping search results based on cluster analysis applied to text fields. A bit like "unsupervised" faceting. -* <>: How to use Solr's spatial search capabilities. -* <>: Detailed information about accessing indexed terms and the documents that include them. -* <>: How to get term information about specific documents. -* <>: How to return information from numeric fields within a document set. -* <>: How to force documents to the top of the results for certain queries. -* <>: The SolrTextTagger, for basic named entity tagging in text. -* <>: Detailed information about configuring and using Solr's response writers. -* <>: How to include documents in search results nearly immediately after they are indexed. -* <>: How to get the latest version of a document without opening a searcher. -* <>: Functionality to export large result sets out of Solr. -* <>: An interface for sending SQL statements to Solr, and using advanced parallel query processing and relational algebra for complex data analysis. -* <>: A framework to compute complex analytics over a result set. +* <>: Detailed information about using `DocTransformers` to add computed information to individual documents +* <>: Detailed information about constructing nested and hierarchical queries. +* <>: Detailed information about Solr's powerful autosuggest component. +* <>: Detailed information about Solr's similar results query component. +* <>: Detailed information about fetching paginated results for display in a UI, or for fetching all documents matching a query. +* <>: Detailed information about grouping results based on common field values. +* <>: Detailed information about grouping search results based on cluster analysis applied to text fields. A bit like "unsupervised" faceting. +* <>: How to use Solr's spatial search capabilities. +* <>: Detailed information about accessing indexed terms and the documents that include them. +* <>: How to get term information about specific documents. +* <>: How to return information from numeric fields within a document set. +* <>: How to force documents to the top of the results for certain queries. +* <>: The SolrTextTagger, for basic named entity tagging in text. +* <>: Detailed information about configuring and using Solr's response writers. +* <>: How to include documents in search results nearly immediately after they are indexed. +* <>: How to get the latest version of a document without opening a searcher. +* <>: Functionality to export large result sets out of Solr. +* <>: An interface for sending SQL statements to Solr, and using advanced parallel query processing and relational algebra for complex data analysis. +* <>: A framework to compute complex analytics over a result set. diff --git a/solr/solr-ref-guide/src/securing-solr.adoc b/solr/solr-ref-guide/src/securing-solr.adoc index 837256e88f7..9d8807c5afb 100644 --- a/solr/solr-ref-guide/src/securing-solr.adoc +++ b/solr/solr-ref-guide/src/securing-solr.adoc @@ -28,11 +28,11 @@ When planning how to secure Solr, you should consider which of the available fea Encrypting traffic to/from Solr and between Solr nodes prevents sensitive data to be leaked out on the network. TLS is also normally a requirement to prevent credential sniffing when using Authentication. -See the page <> for details. +See the page <> for details. == Authentication, Authorization and Audit Logging -See chapter <> to learn how to work with the `security.json` file. +See chapter <> to learn how to work with the `security.json` file. [#securing-solr-auth-plugins] === Authentication Plugins @@ -40,11 +40,11 @@ See chapter <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> // end::list-of-authentication-plugins[] === Authorization Plugins @@ -52,13 +52,13 @@ Authentication makes sure you know the identity of your users. The authenticatio Authorization makes sure that only users with the necessary roles/permissions can access any given resource. The authorization plugins shipping with Solr are: // tag::list-of-authorization-plugins[] -* <> -* <> +* <> +* <> // end::list-of-authorization-plugins[] === Audit Logging Plugins -Audit logging will record an audit trail of incoming reqests to your cluster, such as users being denied access to admin APIs. Learn more about audit logging and how to implement an audit logger plugin here in the <> chapter. +Audit logging will record an audit trail of incoming reqests to your cluster, such as users being denied access to admin APIs. Learn more about audit logging and how to implement an audit logger plugin here in the <> chapter. == Request Logging @@ -79,7 +79,7 @@ SOLR_IP_BLACKLIST="192.168.0.3, 192.168.0.4" == Securing ZooKeeper Traffic ZooKeeper is a central and important part of a SolrCloud cluster and understanding how to secure -its content is covered in the <> page. +its content is covered in the <> page. == Network Configuration diff --git a/solr/solr-ref-guide/src/setting-up-an-external-zookeeper-ensemble.adoc b/solr/solr-ref-guide/src/setting-up-an-external-zookeeper-ensemble.adoc index 48a73454ee3..4a3220978b2 100644 --- a/solr/solr-ref-guide/src/setting-up-an-external-zookeeper-ensemble.adoc +++ b/solr/solr-ref-guide/src/setting-up-an-external-zookeeper-ensemble.adoc @@ -433,4 +433,4 @@ set SOLR_OPTS=%SOLR_OPTS% -Djute.maxbuffer=0x200000 You may also want to secure the communication between ZooKeeper and Solr. -To setup ACL protection of znodes, see the section <>. +To setup ACL protection of znodes, see the section <>. diff --git a/solr/solr-ref-guide/src/shard-management.adoc b/solr/solr-ref-guide/src/shard-management.adoc index d06366673fa..0bee78736b4 100644 --- a/solr/solr-ref-guide/src/shard-management.adoc +++ b/solr/solr-ref-guide/src/shard-management.adoc @@ -81,7 +81,7 @@ A float value (default is 0.0f, must be smaller than 0.5f) that allows to vary t by this percentage of total shard range, odd shards being larger and even shards being smaller. `property._name_=_value_`:: -Set core property _name_ to _value_. See the section <> for details on supported properties and values. +Set core property _name_ to _value_. See the section <> for details on supported properties and values. `waitForFinalState`:: If `true`, the request will complete only when all affected replicas become active. The default is `false`, which means that the API will return the status of the single action, which may be before the new replica is online and active. @@ -232,7 +232,7 @@ The number of `tlog` replicas that should be created for the new shard (optional The number of `pull` replicas that should be created for the new shard (optional, the defaults for the collection is used if omitted) `property._name_=_value_`:: -Set core property _name_ to _value_. See the section <> for details on supported properties and values. +Set core property _name_ to _value_. See the section <> for details on supported properties and values. `waitForFinalState`:: If `true`, the request will complete only when all affected replicas become active. The default is `false`, which means that the API will return the status of the single action, which may be before the new replica is online and active. diff --git a/solr/solr-ref-guide/src/simulations.adoc b/solr/solr-ref-guide/src/simulations.adoc index 349aac6b1f3..b468a5aee11 100644 --- a/solr/solr-ref-guide/src/simulations.adoc +++ b/solr/solr-ref-guide/src/simulations.adoc @@ -56,7 +56,7 @@ the `change_d` vector. Notice that the `conv` function is simply "convolving" the `change_d` vector with a reversed copy of itself. This is the technique for performing autocorrelation using convolution. -The <> section +The <> section of the user guide covers both convolution and autocorrelation in detail. In this section we'll just discuss the plot. diff --git a/solr/solr-ref-guide/src/solr-configuration-files.adoc b/solr/solr-ref-guide/src/solr-configuration-files.adoc index 1815f45e9fa..862bfc48cc4 100644 --- a/solr/solr-ref-guide/src/solr-configuration-files.adoc +++ b/solr/solr-ref-guide/src/solr-configuration-files.adoc @@ -66,13 +66,13 @@ You may see other files, but the main ones you need to know are discussed in the == Configuration Files Inside Solr's Home, you'll find these files: -* `solr.xml` specifies configuration options for your Solr server instance. For more information on `solr.xml` see <>. +* `solr.xml` specifies configuration options for your Solr server instance. For more information on `solr.xml` see <>. * Per Solr Core: -** `core.properties` defines specific properties for each core such as its name, the collection the core belongs to, the location of the schema, and other parameters. For more details on `core.properties`, see the section <>. -** `solrconfig.xml` controls high-level behavior. You can, for example, specify an alternate location for the data directory. For more information on `solrconfig.xml`, see <>. -** `managed-schema` (or `schema.xml` instead) describes the documents you will ask Solr to index. The Schema define a document as a collection of fields. You get to define both the field types and the fields themselves. Field type definitions are powerful and include information about how Solr processes incoming field values and query values. For more information on Solr Schemas, see <> and the <>. +** `core.properties` defines specific properties for each core such as its name, the collection the core belongs to, the location of the schema, and other parameters. For more details on `core.properties`, see the section <>. +** `solrconfig.xml` controls high-level behavior. You can, for example, specify an alternate location for the data directory. For more information on `solrconfig.xml`, see <>. +** `managed-schema` (or `schema.xml` instead) describes the documents you will ask Solr to index. The Schema define a document as a collection of fields. You get to define both the field types and the fields themselves. Field type definitions are powerful and include information about how Solr processes incoming field values and query values. For more information on Solr Schemas, see <> and the <>. ** `data/` The directory containing the low level index files. Note that the SolrCloud example does not include a `conf` directory for each Solr Core (so there is no `solrconfig.xml` or Schema file). This is because the configuration files usually found in the `conf` directory are stored in ZooKeeper so they can be propagated across the cluster. -If you are using SolrCloud with the embedded ZooKeeper instance, you may also see `zoo.cfg` and `zoo.data` which are ZooKeeper configuration and data files. However, if you are running your own ZooKeeper ensemble, you would supply your own ZooKeeper configuration file when you start it and the copies in Solr would be unused. For more information about SolrCloud, see the section <>. +If you are using SolrCloud with the embedded ZooKeeper instance, you may also see `zoo.cfg` and `zoo.data` which are ZooKeeper configuration and data files. However, if you are running your own ZooKeeper ensemble, you would supply your own ZooKeeper configuration file when you start it and the copies in Solr would be unused. For more information about SolrCloud, see the section <>. 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 88d7c4580bc..499d74ebb9d 100644 --- a/solr/solr-ref-guide/src/solr-control-script-reference.adoc +++ b/solr/solr-ref-guide/src/solr-control-script-reference.adoc @@ -22,7 +22,7 @@ You can start and stop Solr, create and delete collections or cores, perform ope You can find the script in the `bin/` directory of your Solr installation. The `bin/solr` script makes Solr easier to work with by providing simple commands and options to quickly accomplish common goals. -More examples of `bin/solr` in use are available throughout the Solr Reference Guide, but particularly in the sections <> and <>. +More examples of `bin/solr` in use are available throughout the Solr Reference Guide, but particularly in the sections <> and <>. == Starting and Stopping @@ -183,7 +183,7 @@ To do this use the `mkroot` command outlined below, for example: `bin/solr zk mk When starting in SolrCloud mode, the interactive script session will prompt you to choose a configset to use. -For more information about starting Solr in SolrCloud mode, see also the section <>. +For more information about starting Solr in SolrCloud mode, see also the section <>. ==== Running with Example Configurations @@ -191,11 +191,11 @@ For more information about starting Solr in SolrCloud mode, see also the section The example configurations allow you to get started quickly with a configuration that mirrors what you hope to accomplish with Solr. -Each example launches Solr with a managed schema, which allows use of the <> to make schema edits, but does not allow manual editing of a Schema file. +Each example launches Solr with a managed schema, which allows use of the <> to make schema edits, but does not allow manual editing of a Schema file. -If you would prefer to manually modify a `schema.xml` file directly, you can change this default as described in the section <>. +If you would prefer to manually modify a `schema.xml` file directly, you can change this default as described in the section <>. -Unless otherwise noted in the descriptions below, the examples do not enable <> nor <>. +Unless otherwise noted in the descriptions below, the examples do not enable <> nor <>. The following examples are provided: @@ -205,7 +205,7 @@ When using this example, you can choose from any of the available configsets fou * *techproducts*: This example starts Solr in standalone mode with a schema designed for the sample documents included in the `$SOLR_HOME/example/exampledocs` directory. + The configset used can be found in `$SOLR_HOME/server/solr/configsets/sample_techproducts_configs`. -* *schemaless*: This example starts Solr in standalone mode using a managed schema, as described in the section <>, and provides a very minimal pre-defined schema. Solr will run in <> with this configuration, where Solr will create fields in the schema on the fly and will guess field types used in incoming documents. +* *schemaless*: This example starts Solr in standalone mode using a managed schema, as described in the section <>, and provides a very minimal pre-defined schema. Solr will run in <> with this configuration, where Solr will create fields in the schema on the fly and will guess field types used in incoming documents. + The configset used can be found in `$SOLR_HOME/server/solr/configsets/_default`. @@ -504,7 +504,7 @@ Currently, this script only enables Basic Authentication, and is only available The command `bin/solr auth enable` configures Solr to use Basic Authentication when accessing the User Interface, using `bin/solr` and any API requests. -TIP: For more information about Solr's authentication plugins, see the section <>. For more information on Basic Authentication support specifically, see the section <>. +TIP: For more information about Solr's authentication plugins, see the section <>. For more information on Basic Authentication support specifically, see the section <>. The `bin/solr auth enable` command makes several changes to enable Basic Authentication: @@ -598,7 +598,7 @@ To unset a previously set common property, specify `-action unset-property` with === Set or Unset User-defined Properties -To set the user-defined property `update.autoCreateFields` to `false` (to disable <>): +To set the user-defined property `update.autoCreateFields` to `false` (to disable <>): `bin/solr config -c mycollection -p 8983 -action set-user-property -property update.autoCreateFields -value false` @@ -916,7 +916,7 @@ bin/solr export -url http://localhost:8983/solr/gettingstarted -1 -out 1MDocs.js === Importing Documents to a Collection -Once you have exported documents in a file, you can use the <> to import them to a new Solr collection. +Once you have exported documents in a file, you can use the <> to import them to a new Solr collection. *Example: import `jsonl` files* diff --git a/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc b/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc index 4e866837e92..a8b30a8e09e 100644 --- a/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc +++ b/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc @@ -30,7 +30,7 @@ In older versions of Solr, cores had to be predefined as `` tags in `solr. The following sections describe these options in more detail. -* *<>*: Details on how to define `solr.xml`, including the acceptable parameters for the `solr.xml` file -* *<>*: Details on placement of `core.properties` and available property options. -* *<>*: Tools and commands for core administration using a REST API. -* *<>*: How to use configsets to avoid duplicating effort when defining a new core. +* *<>*: Details on how to define `solr.xml`, including the acceptable parameters for the `solr.xml` file +* *<>*: Details on placement of `core.properties` and available property options. +* *<>*: Tools and commands for core administration using a REST API. +* *<>*: How to use configsets to avoid duplicating effort when defining a new core. diff --git a/solr/solr-ref-guide/src/solr-field-types.adoc b/solr/solr-ref-guide/src/solr-field-types.adoc index 3dd9fe72b33..0b4d4d21b5b 100644 --- a/solr/solr-ref-guide/src/solr-field-types.adoc +++ b/solr/solr-ref-guide/src/solr-field-types.adoc @@ -21,18 +21,18 @@ The field type defines how Solr should interpret data in a field and how the fie Topics covered in this section: -* <> +* <> -* <> +* <> -* <> +* <> -* <> +* <> -* <> +* <> -* <> +* <> -* <> +* <> TIP: See also the {solr-javadocs}/core/org/apache/solr/schema/FieldType.html[FieldType Javadoc]. diff --git a/solr/solr-ref-guide/src/solr-glossary.adoc b/solr/solr-ref-guide/src/solr-glossary.adoc index 27f1c7e4e06..296eccbbbde 100644 --- a/solr/solr-ref-guide/src/solr-glossary.adoc +++ b/solr/solr-ref-guide/src/solr-glossary.adoc @@ -142,39 +142,39 @@ The appropriateness of a document to the search conducted by the user. [[replica]]Replica:: A <> that acts as a physical copy of a <> in a <> <>. -[[replication]]<>:: +[[replication]]<>:: A method of copying a leader index from one server to one or more "follower" or "child" servers. -[[requesthandler]]<>:: +[[requesthandler]]<>:: Logic and configuration parameters that tell Solr how to handle incoming "requests", whether the requests are to return search results, to index documents, or to handle other custom situations. [[SolrGlossary-S]] === S -[[searchcomponent]]<>:: +[[searchcomponent]]<>:: Logic and configuration parameters used by request handlers to process query requests. Examples of search components include faceting, highlighting, and "more like this" functionality. [[shard]]Shard:: In SolrCloud, a logical partition of a single <>. Every shard consists of at least one physical <>, but there may be multiple Replicas distributed across multiple <> for fault tolerance. See also <>. -[[solrclouddef]]<>:: +[[solrclouddef]]<>:: Umbrella term for a suite of functionality in Solr which allows managing a <> of Solr <> for scalability, fault tolerance, and high availability. -[[schema]]<>:: -The Solr index Schema defines the fields to be indexed and the type for the field (text, integers, etc.) By default schema data can be "managed" at run time using the <> and is typically kept in a file named `managed-schema` which Solr modifies as needed, but a collection may be configured to use a static Schema, which is only loaded on startup from a human edited configuration file - typically named `schema.xml`. See <> for details. +[[schema]]<>:: +The Solr index Schema defines the fields to be indexed and the type for the field (text, integers, etc.) By default schema data can be "managed" at run time using the <> and is typically kept in a file named `managed-schema` which Solr modifies as needed, but a collection may be configured to use a static Schema, which is only loaded on startup from a human edited configuration file - typically named `schema.xml`. See <> for details. -[[solrconfig]]<>:: +[[solrconfig]]<>:: The Apache Solr configuration file. Defines indexing options, RequestHandlers, highlighting, spellchecking and various other configurations. The file, `solrconfig.xml`, is located in the Solr home `conf` directory. -[[spellcheck]]<>:: +[[spellcheck]]<>:: The ability to suggest alternative spellings of search terms to a user, as a check against spelling errors causing few or zero results. [[stopwords]]Stopwords:: Generally, words that have little meaning to a user's search but which may have been entered as part of a <> query. Stopwords are generally very small pronouns, conjunctions and prepositions (such as, "the", "with", or "and") -[[suggesterdef]]<>:: +[[suggesterdef]]<>:: Functionality in Solr that provides the ability to suggest possible query terms to users as they type. [[synonyms]]Synonyms:: diff --git a/solr/solr-ref-guide/src/solr-plugins.adoc b/solr/solr-ref-guide/src/solr-plugins.adoc index 3d12f50754f..565b7bbd5af 100644 --- a/solr/solr-ref-guide/src/solr-plugins.adoc +++ b/solr/solr-ref-guide/src/solr-plugins.adoc @@ -35,9 +35,9 @@ One resource is the Solr Wiki documentation on plugins at https://cwiki.apache.o There are essentially two types of plugins in Solr: -* Collection level plugins. These are registered on individual collections, either by hand-editing the `solrconfig.xml` or schema files for the collection's configset or by using the <> or <>. Examples of these are query parsers, request handlers, update request processors, value source parsers, response writers etc. +* Collection level plugins. These are registered on individual collections, either by hand-editing the `solrconfig.xml` or schema files for the collection's configset or by using the <> or <>. Examples of these are query parsers, request handlers, update request processors, value source parsers, response writers etc. -* Cluster level (or Core Container level) plugins. These are plugins that are installed at a cluster level and every Solr node has one instance each of these plugins. Examples of these are <>, <>, https://issues.apache.org/jira/browse/SOLR-14404[cluster level request handlers] etc. +* Cluster level (or Core Container level) plugins. These are plugins that are installed at a cluster level and every Solr node has one instance each of these plugins. Examples of these are <>, <>, https://issues.apache.org/jira/browse/SOLR-14404[cluster level request handlers] etc. == Installing Plugins == @@ -53,11 +53,11 @@ This has been the standard approach since Solr's inception. It's simple and reliable but it's entirely on you to ensure that all nodes in a cluster have them. Contrib modules ship with Solr so there's no effort for them but not so for other plugins (yours or 3rd party). -* <>: +* <>: Describes a new and experimental system to manage packages of plugins in SolrCloud. It includes CLI commands, cluster-wide installation, use of plugin registries that host plugins, cryptographically signed plugins for security, and more. Only some plugins support this as of now (support for more types of plugins coming soon). -* <>: +* <>: Describes the API used for managing cluster-level plugins such as request handlers, -cluster-level event producer and <>. +cluster-level event producer and <>. diff --git a/solr/solr-ref-guide/src/solr-tutorial.adoc b/solr/solr-ref-guide/src/solr-tutorial.adoc index 6da43f573dc..811b8c7d7e0 100644 --- a/solr/solr-ref-guide/src/solr-tutorial.adoc +++ b/solr/solr-ref-guide/src/solr-tutorial.adoc @@ -475,7 +475,7 @@ This time you get 13 results. ==== More Information on Searching -We have only scratched the surface of the search options available in Solr. For more Solr search options, see the section on <>. +We have only scratched the surface of the search options available in Solr. For more Solr search options, see the section on <>. === Exercise 1 Wrap Up @@ -493,7 +493,7 @@ To stop both of the Solr nodes we started, issue the command: `bin/solr stop -all` -For more information on start/stop and collection options with `bin/solr`, see <>. +For more information on start/stop and collection options with `bin/solr`, see <>. [[exercise-2]] == Exercise 2: Modify the Schema and Index Films Data @@ -747,7 +747,7 @@ If you wanted to control the number of items in a bucket, you could do something You should only see 4 facets returned. -There are a great deal of other parameters available to help you control how Solr constructs the facets and facet lists. We'll cover some of them in this exercise, but you can also see the section <> for more detail. +There are a great deal of other parameters available to help you control how Solr constructs the facets and facet lists. We'll cover some of them in this exercise, but you can also see the section <> for more detail. ==== Range Facets @@ -909,10 +909,10 @@ In this example, assume there is a directory named "Documents" locally. To index You may get errors as it works through your documents. These might be caused by the field guessing, or the file type may not be supported. Indexing content such as this demonstrates the need to plan Solr for your data, which requires understanding it and perhaps also some trial and error. SolrJ:: -SolrJ is a Java-based client for interacting with Solr. Use <> for JVM-based languages or other <> to programmatically create documents to send to Solr. +SolrJ is a Java-based client for interacting with Solr. Use <> for JVM-based languages or other <> to programmatically create documents to send to Solr. Documents Screen:: -Use the Admin UI <> (at http://localhost:8983/solr/#/localDocs/documents) to paste in a document to be indexed, or select `Document Builder` from the `Document Type` dropdown to build a document one field at a time. Click on the btn:[Submit Document] button below the form to index your document. +Use the Admin UI <> (at http://localhost:8983/solr/#/localDocs/documents) to paste in a document to be indexed, or select `Document Builder` from the `Document Type` dropdown to build a document one field at a time. Click on the btn:[Submit Document] button below the form to index your document. === Updating Data @@ -952,7 +952,7 @@ Solr has sophisticated geospatial support, including searching within a specifie Some of the example techproducts documents we indexed in Exercise 1 have locations associated with them to illustrate the spatial capabilities. To reindex this data, see <>. -To learn more about Solr's spatial capabilities, see the section <>. +To learn more about Solr's spatial capabilities, see the section <>. == Wrapping Up diff --git a/solr/solr-ref-guide/src/solr-upgrade-notes.adoc b/solr/solr-ref-guide/src/solr-upgrade-notes.adoc index c4f29b5243d..3bfbf02e9d0 100644 --- a/solr/solr-ref-guide/src/solr-upgrade-notes.adoc +++ b/solr/solr-ref-guide/src/solr-upgrade-notes.adoc @@ -28,7 +28,7 @@ your system and review the {solr-javadocs}/changes/Changes.html[`CHANGES.txt`] file found in your Solr package. That file includes all the changes and updates that may effect your existing implementation. -Detailed steps for upgrading a Solr cluster are in the section <>. +Detailed steps for upgrading a Solr cluster are in the section <>. == Upgrading to 9.x Releases (NOT RELEASED) @@ -127,11 +127,11 @@ The Solr community is working on pluggable API to replace this functionality, wi * Solr has replaced the terms "master" and "slave" in the codebase and all documentation with "leader" and "follower". + -This impacts the functionality described in the section <>. +This impacts the functionality described in the section <>. This functionality has only changed in terms of parameter names changed, and we do not expect any back-compatibility issues on upgrade to 8.7 or even 9.0 later. + However, users should update their `solrconfig.xml` files after completing the upgrade on all nodes of a cluster. -Comparing your configuration to the updated configuration examples in <> will show examples of what needs to change, but here are the main changes: +Comparing your configuration to the updated configuration examples in <> will show examples of what needs to change, but here are the main changes: + . On the replication leader, in the definition of the `/replication` request handler: .. Replace "master" with "leader". @@ -404,7 +404,7 @@ to Solr. The system is currently considered experimental, so use with caution. It must be enabled with a system parameter passed at start up before it can be used. -For details, please see the section <>. +For details, please see the section <>. With this feature Solr's Blob Store functionality is now deprecated and will likely be removed in 9.0. @@ -423,7 +423,7 @@ the `/browse` sample search interface) are no longer enabled out of the box. ** The XSLT and Velocity response writers. + All of these items can be added to your Solr implementation by manually editing -`solrconfig.xml` to add them back in, or use the <>. +`solrconfig.xml` to add them back in, or use the <>. + The `sample_techproducts_configs` and the examples found in `./example` are unchanged. @@ -437,9 +437,9 @@ When upgrading to 8.4, if you are using untrusted configsets that contain `> +** You can secure your Solr instance with <> and re-upload the configset (using the `bin/solr zk upconfig ...` -<> command); +<> command); ** You can put your custom Jars in Solr's classpath instead of `lib` directories; ** You can try the new package management system to manage your custom Jars. + @@ -462,8 +462,8 @@ As a result of this change, any custom HTML served by Solr's HTTP server that co *Using Collapse with Group Disallowed* -Using the <> -with <> has never been +Using the <> +with <> has never been supported as it causes inconsistent behavior and NullPointerException errors. We have now explicitly disallowed this combination to prevent these errors. If you are using these together, you will need to modify your queries. @@ -532,7 +532,7 @@ Since caching has a direct impact on the performance of your Solr * A new parameter, `maxIdleTime`, allows automatic eviction of cache items that have not been used in the defined amount of time. This allows the cache to release some memory and should aid those who want or need to fine-tune their caches. -See the section <> for more details about these and other cache options and parameters. +See the section <> for more details about these and other cache options and parameters. === Solr 8.2 @@ -570,7 +570,7 @@ Collections created with older versions will continue to work. *Distributed Tracing Support* -This release adds support for tracing requests in Solr. Please review the section <> for details on how to configure this feature. +This release adds support for tracing requests in Solr. Please review the section <> for details on how to configure this feature. === Solr 8.1 @@ -592,9 +592,9 @@ For more information about the new parameter, see the section <>. +* JSON Web Tokens (JWT) are now supported for authentication. These allow Solr to assert a user is already authenticated via an external identity provider, such as an OpenID Connect-enabled IdP. For more information, see the section <>. -* A new security plugin for audit logging has been added. A default class `SolrLogAuditLoggerPlugin` is available and configurable in `security.json`. The base class is also extendable for adding custom audit plugins if needed. See the section <> for more information. +* A new security plugin for audit logging has been added. A default class `SolrLogAuditLoggerPlugin` is available and configurable in `security.json`. The base class is also extendable for adding custom audit plugins if needed. See the section <> for more information. *Collections API* @@ -630,7 +630,7 @@ If even this slight risk is unacceptable, the Log4j configuration file found in == Upgrading from 7.x Releases The upgrade from 7.x to Solr 8.0 introduces several major changes that you should be aware of before upgrading. -These changes are described in the section <>. It's strongly recommended that you do a thorough review of that section before starting your upgrade. +These changes are described in the section <>. It's strongly recommended that you do a thorough review of that section before starting your upgrade. [NOTE] If you run in SolrCloud mode, you must be on Solr version 7.3 or higher in order to upgrade to 8.x. @@ -639,6 +639,6 @@ If you run in SolrCloud mode, you must be on Solr version 7.3 or higher in order Users upgrading from versions of Solr prior to 7.x are strongly encouraged to consult {solr-javadocs}/changes/Changes.html[`CHANGES.txt`] for the details of _all_ changes since the version they are upgrading from. -The upgrade from Solr 6.x to Solr 7.0 introduced several *major* changes that you should be aware of before upgrading. Please do a thorough review of the section <> before starting your upgrade. +The upgrade from Solr 6.x to Solr 7.0 introduced several *major* changes that you should be aware of before upgrading. Please do a thorough review of the section <> before starting your upgrade. -A summary of the significant changes between Solr 5.x and Solr 6.0 is in the section <>. +A summary of the significant changes between Solr 5.x and Solr 6.0 is in the section <>. diff --git a/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc b/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc index 572b974470b..dce441a040d 100644 --- a/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc +++ b/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc @@ -21,12 +21,12 @@ In this section, we'll cover the various configuration options for SolrCloud. The following sections cover these topics: -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> diff --git a/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc b/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc index 56ba861244d..7aaa30427d8 100644 --- a/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc +++ b/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc @@ -73,7 +73,7 @@ If `shards.tolerant=true` then partial results may be returned. If the returned If `shards.tolerant=requireZkConnected` and the node serving the search request cannot communicate with ZooKeeper, the request will fail, rather than returning potentially stale or incorrect results. This will also cause requests to fail when one or more queried shards are completely unavailable, just like when `shards.tolerant=false`. -The client can specify '<>' along with the `shards.tolerant` parameter to retrieve more fine-grained details. +The client can specify '<>' along with the `shards.tolerant` parameter to retrieve more fine-grained details. Example response with `partialResults` flag set to `true`: diff --git a/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc b/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc index 491861a6bdc..f515f870ff2 100644 --- a/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc +++ b/solr/solr-ref-guide/src/solrcloud-recoveries-and-write-tolerance.adoc @@ -20,7 +20,7 @@ SolrCloud is highly available and fault tolerant in reads and writes. == Write Side Fault Tolerance -SolrCloud is designed to replicate documents to ensure redundancy for your data, and enable you to send update requests to any node in the cluster. That node will determine if it hosts the leader for the appropriate shard, and if not it will forward the request to the the leader, which will then forward it to all existing replicas, using versioning to make sure every replica has the most up-to-date version. If the leader goes down, another replica can take its place. This architecture enables you to be certain that your data can be recovered in the event of a disaster, even if you are using <>. +SolrCloud is designed to replicate documents to ensure redundancy for your data, and enable you to send update requests to any node in the cluster. That node will determine if it hosts the leader for the appropriate shard, and if not it will forward the request to the the leader, which will then forward it to all existing replicas, using versioning to make sure every replica has the most up-to-date version. If the leader goes down, another replica can take its place. This architecture enables you to be certain that your data can be recovered in the event of a disaster, even if you are using <>. === Recovery diff --git a/solr/solr-ref-guide/src/solrcloud-resilience.adoc b/solr/solr-ref-guide/src/solrcloud-resilience.adoc index 106804ca52e..4010a53dbd2 100644 --- a/solr/solr-ref-guide/src/solrcloud-resilience.adoc +++ b/solr/solr-ref-guide/src/solrcloud-resilience.adoc @@ -21,6 +21,6 @@ In this section, we'll cover how does Solr handle reads and writes when all the The following sections cover these topics: -* <> -* <> +* <> +* <> diff --git a/solr/solr-ref-guide/src/solrcloud.adoc b/solr/solr-ref-guide/src/solrcloud.adoc index b063a3f09f3..3327744e152 100644 --- a/solr/solr-ref-guide/src/solrcloud.adoc +++ b/solr/solr-ref-guide/src/solrcloud.adoc @@ -27,19 +27,19 @@ SolrCloud is flexible distributed search and indexing, without a leader node to In this section, we'll cover everything you need to know about using Solr in SolrCloud mode. We've split up the details into the following topics: -* <> -* <> -** <> -** <> -* <> -** <> -** <> -* <> -** <> -** <> -** <> -** <> -** <> -** <> -** <> -** <> \ No newline at end of file +* <> +* <> +** <> +** <> +* <> +** <> +** <> +* <> +** <> +** <> +** <> +** <> +** <> +** <> +** <> +** <> diff --git a/solr/solr-ref-guide/src/spatial-search.adoc b/solr/solr-ref-guide/src/spatial-search.adoc index 6a6fda09454..30acd01e08b 100644 --- a/solr/solr-ref-guide/src/spatial-search.adoc +++ b/solr/solr-ref-guide/src/spatial-search.adoc @@ -83,7 +83,7 @@ The center point using the format "lat,lon" if latitude & longitude. Otherwise, A spatial indexed field. `score`:: -(Advanced option; not supported by LatLonType (deprecated) or PointType) If the query is used in a scoring context (e.g., as the main query in `q`), this _<>_ determines what scores will be produced. Valid values are: +(Advanced option; not supported by LatLonType (deprecated) or PointType) If the query is used in a scoring context (e.g., as the main query in `q`), this _<>_ determines what scores will be produced. Valid values are: * `none`: A fixed score of 1.0. (the default) * `kilometers`: distance in kilometers between the field value and the specified center point @@ -169,7 +169,7 @@ There are four distance function queries: * <>, to calculate the distance between two points on a sphere; * <>, to calculate the squared Euclidean distance between two points. -For more information about these function queries, see the section on <>. +For more information about these function queries, see the section on <>. === geodist @@ -207,7 +207,7 @@ There are other ways to do it too, like using a `{!geofilt}` in each facet.query === Boost Nearest Results -Using the <> or <>, you can combine spatial search with the boost function to boost the nearest results: +Using the <> or <>, you can combine spatial search with the boost function to boost the nearest results: [source,text] &q.alt=*:*&fq={!geofilt}&sfield=store&pt=45.15,-93.85&d=50&bf=recip(geodist(),2,200,20)&sort=score desc @@ -381,7 +381,7 @@ An optional in-memory cache can be defined in `solrconfig.xml`, which should be regenerator="solr.NoOpRegenerator"/> ---- -When using this field type, you will likely _not_ want to mark the field as stored because it's redundant with the DocValues data and surely larger because of the formatting (be it WKT or GeoJSON). To retrieve the spatial data in search results from DocValues, use the `[geo]` transformer -- <>. +When using this field type, you will likely _not_ want to mark the field as stored because it's redundant with the DocValues data and surely larger because of the formatting (be it WKT or GeoJSON). To retrieve the spatial data in search results from DocValues, use the `[geo]` transformer -- <>. === Heatmap Faceting diff --git a/solr/solr-ref-guide/src/spell-checking.adoc b/solr/solr-ref-guide/src/spell-checking.adoc index 1611b5d3bef..1f2250e3914 100644 --- a/solr/solr-ref-guide/src/spell-checking.adoc +++ b/solr/solr-ref-guide/src/spell-checking.adoc @@ -140,7 +140,7 @@ The spellchecker can be configured with a traditional checker (i.e., `DirectSolr === Add It to a Request Handler -Queries will be sent to a <>. If every request should generate a suggestion, then you would add the following to the `requestHandler` that you are using: +Queries will be sent to a <>. If every request should generate a suggestion, then you would add the following to the `requestHandler` that you are using: [source,xml] ---- @@ -303,7 +303,7 @@ Results: The `SpellCheckComponent` also supports spellchecking on distributed indexes. If you are using the SpellCheckComponent on a request handler other than "/select", you must provide the following two parameters: `shards`:: -Specifies the shards in your distributed indexing configuration. For more information about distributed indexing, see <> +Specifies the shards in your distributed indexing configuration. For more information about distributed indexing, see <> `shards.qt`:: Specifies the request handler Solr uses for requests to shards. This parameter is not required for the `/select` request handler. diff --git a/solr/solr-ref-guide/src/stream-screen.adoc b/solr/solr-ref-guide/src/stream-screen.adoc index 2b95c9f129f..19d26ebddca 100644 --- a/solr/solr-ref-guide/src/stream-screen.adoc +++ b/solr/solr-ref-guide/src/stream-screen.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -The Stream screen allows you to enter a <> and see the results. It is very similar to the <>, except the input box is at the top and all options must be declared in the expression. +The Stream screen allows you to enter a <> and see the results. It is very similar to the <>, except the input box is at the top and all options must be declared in the expression. The screen will insert everything up to the streaming expression itself, so you do not need to enter the full URI with the hostname, port, collection, etc. Simply input the expression after the `expr=` part, and the URL will be constructed dynamically as appropriate. diff --git a/solr/solr-ref-guide/src/stream-source-reference.adoc b/solr/solr-ref-guide/src/stream-source-reference.adoc index e5352b4eed9..0d690314603 100644 --- a/solr/solr-ref-guide/src/stream-source-reference.adoc +++ b/solr/solr-ref-guide/src/stream-source-reference.adoc @@ -21,7 +21,7 @@ The `search` function searches a SolrCloud collection and emits a stream of tuples that match the query. This is very similar to a standard Solr query, and uses many of the same parameters. -This expression allows you to specify a request hander using the `qt` parameter. By default, the `/select` handler is used. The `/select` handler can be used for simple rapid prototyping of expressions. For production, however, you will most likely want to use the `/export` handler which is designed to `sort` and `export` entire result sets. The `/export` handler is not used by default because it has stricter requirements then the `/select` handler so it's not as easy to get started working with. To read more about the `/export` handler requirements review the section <>. +This expression allows you to specify a request hander using the `qt` parameter. By default, the `/select` handler is used. The `/select` handler can be used for simple rapid prototyping of expressions. For production, however, you will most likely want to use the `/export` handler which is designed to `sort` and `export` entire result sets. The `/export` handler is not used by default because it has stricter requirements then the `/select` handler so it's not as easy to get started working with. To read more about the `/export` handler requirements review the section <>. === search Parameters @@ -294,7 +294,7 @@ cat("authors.txt,fiction/scifi/", maxLines=500) == nodes -The `nodes` function provides breadth-first graph traversal. For details, see the section <>. +The `nodes` function provides breadth-first graph traversal. For details, see the section <>. == knnSearch diff --git a/solr/solr-ref-guide/src/streaming-expressions.adoc b/solr/solr-ref-guide/src/streaming-expressions.adoc index ce16e727ae7..df93f985dab 100644 --- a/solr/solr-ref-guide/src/streaming-expressions.adoc +++ b/solr/solr-ref-guide/src/streaming-expressions.adoc @@ -37,13 +37,13 @@ Streaming expressions are comprised of streaming functions which work with a Sol They emit a stream of tuples (key/value Maps). Some of the provided streaming functions are designed to work with entire result sets rather than the top N results like normal search. -This is supported by the <>. +This is supported by the <>. Some streaming functions act as stream sources to originate the stream flow. Other streaming functions act as stream decorators to wrap other stream functions and perform operations on the stream of tuples. Many streams functions can be parallelized across a worker collection. This can be particularly powerful for relational algebra functions. === Streaming Requests and Responses -Solr has a `/stream` request handler that takes streaming expression requests and returns the tuples as a JSON stream. This request handler is implicitly defined, meaning there is nothing that has to be defined in `solrconfig.xml` - see <>. +Solr has a `/stream` request handler that takes streaming expression requests and returns the tuples as a JSON stream. This request handler is implicitly defined, meaning there is nothing that has to be defined in `solrconfig.xml` - see <>. The `/stream` request handler takes one parameter, `expr`, which is used to specify the streaming expression. For example, this curl command encodes and POSTs a simple `search()` expression to the `/stream` handler: @@ -92,14 +92,14 @@ Timeouts for Streaming Expressions can be configured with the `socketTimeout` an Stream sources originate streams. There are rich set of searching, sampling and aggregation stream sources to choose from. -A full reference to all available source expressions is available in <>. +A full reference to all available source expressions is available in <>. === Stream Decorators Stream decorators wrap stream sources and other stream decorators to transform a stream. -A full reference to all available decorator expressions is available in <>. +A full reference to all available decorator expressions is available in <>. === Math Expressions @@ -114,7 +114,7 @@ The math expressions user guide is available in <<>> From a language standpoint math expressions are referred to as *stream evaluators*. -A full reference to all available evaluator expressions is available in <>. +A full reference to all available evaluator expressions is available in <>. === Visualization @@ -123,4 +123,4 @@ Visualization of both streaming expressions and math expressions is done using A Visualizing Streaming expressions and setting up of Apache Zeppelin is documented in <>. -The <> has in depth coverage of visualization techniques. +The <> has in depth coverage of visualization techniques. diff --git a/solr/solr-ref-guide/src/suggester.adoc b/solr/solr-ref-guide/src/suggester.adoc index 95fde7835f0..1e89c06d827 100644 --- a/solr/solr-ref-guide/src/suggester.adoc +++ b/solr/solr-ref-guide/src/suggester.adoc @@ -20,7 +20,7 @@ The SuggestComponent in Solr provides users with automatic suggestions for query You can use this to implement a powerful auto-suggest feature in your search application. -Although it is possible to use the <> functionality to power autosuggest behavior, Solr has a dedicated http://lucene.apache.org/solr/api/solr-core/org/apache/solr/handler/component/SuggestComponent.html[SuggestComponent] designed for this functionality. +Although it is possible to use the <> functionality to power autosuggest behavior, Solr has a dedicated http://lucene.apache.org/solr/api/solr-core/org/apache/solr/handler/component/SuggestComponent.html[SuggestComponent] designed for this functionality. This approach utilizes Lucene's Suggester implementation and supports all of the lookup implementations available in Lucene. @@ -30,7 +30,7 @@ The main features of this Suggester are: * Term dictionary pluggability, giving you the flexibility to choose the dictionary implementation * Distributed support -The `solrconfig.xml` found in Solr's "```techproducts```" example has a Suggester implementation configured already. For more on search components, see the section <>. +The `solrconfig.xml` found in Solr's "```techproducts```" example has a Suggester implementation configured already. For more on search components, see the section <>. The "```techproducts```" example `solrconfig.xml` has a `suggest` search component and a `/suggest` request handler already configured. You can use that as the basis for your configuration, or create it from scratch, as detailed below. @@ -78,7 +78,7 @@ If not set, the default dictionary implementation is `HighFrequencyDictionaryFac `field`:: A field from the index to use as the basis of suggestion terms. If `sourceLocation` is empty (meaning any dictionary implementation other than `FileDictionaryFactory`), then terms from this field in the index will be used. + -To be used as the basis for a suggestion, the field must be stored. You may want to <> to create a special 'suggest' field comprised of terms from other fields in documents. In any event, you very likely want a minimal amount of analysis on the field, so an additional option is to create a field type in your schema that only uses basic tokenizers or filters. One option for such a field type is shown here: +To be used as the basis for a suggestion, the field must be stored. You may want to <> to create a special 'suggest' field comprised of terms from other fields in documents. In any event, you very likely want a minimal amount of analysis on the field, so an additional option is to create a field type in your schema that only uses basic tokenizers or filters. One option for such a field type is shown here: + [source,xml] ---- @@ -349,7 +349,7 @@ When using these Suggesters in a query, you would define multiple `suggest.dicti == Adding the Suggest Request Handler -After adding the search component, a request handler must be added to `solrconfig.xml`. This request handler works the <>, and allows you to configure default parameters for serving suggestion requests. The request handler definition must incorporate the "suggest" search component defined previously. +After adding the search component, a request handler must be added to `solrconfig.xml`. This request handler works the <>, and allows you to configure default parameters for serving suggestion requests. The request handler definition must incorporate the "suggest" search component defined previously. [source,xml] ---- diff --git a/solr/solr-ref-guide/src/taking-solr-to-production.adoc b/solr/solr-ref-guide/src/taking-solr-to-production.adoc index 4bf92e77a65..de5e5101cbd 100644 --- a/solr/solr-ref-guide/src/taking-solr-to-production.adoc +++ b/solr/solr-ref-guide/src/taking-solr-to-production.adoc @@ -44,7 +44,7 @@ You should also separate writable Solr files into a different directory; by defa === Create the Solr User -Running Solr as `root` is not recommended for security reasons, and the <> start command will refuse to do so. Consequently, you should determine the username of a system user that will own all of the Solr files and the running Solr process. By default, the installation script will create the *solr* user, but you can override this setting using the -u option. If your organization has specific requirements for creating new user accounts, then you should create the user before running the script. The installation script will make the Solr user the owner of the `/opt/solr` and `/var/solr` directories. +Running Solr as `root` is not recommended for security reasons, and the <> start command will refuse to do so. Consequently, you should determine the username of a system user that will own all of the Solr files and the running Solr process. By default, the installation script will create the *solr* user, but you can override this setting using the -u option. If your organization has specific requirements for creating new user accounts, then you should create the user before running the script. The installation script will make the Solr user the owner of the `/opt/solr` and `/var/solr` directories. You are now ready to run the installation script. @@ -91,7 +91,7 @@ We'll cover some additional configuration settings you can make to fine-tune you ==== Solr Home Directory -The Solr home directory (not to be confused with the Solr installation directory) is where Solr manages core directories with index files. By default, the installation script uses `/var/solr/data`. If the `-d` option is used on the install script, then this will change to the `data` subdirectory in the location given to the -d option. Take a moment to inspect the contents of the Solr home directory on your system. If you do not <>, the home directory must contain a `solr.xml` file. When Solr starts up, the Solr Control Script passes the location of the home directory using the `-Dsolr.solr.home=...` system property. +The Solr home directory (not to be confused with the Solr installation directory) is where Solr manages core directories with index files. By default, the installation script uses `/var/solr/data`. If the `-d` option is used on the install script, then this will change to the `data` subdirectory in the location given to the -d option. Take a moment to inspect the contents of the Solr home directory on your system. If you do not <>, the home directory must contain a `solr.xml` file. When Solr starts up, the Solr Control Script passes the location of the home directory using the `-Dsolr.solr.home=...` system property. ==== Environment Overrides Include File @@ -103,7 +103,7 @@ SOLR_PID_DIR=/var/solr SOLR_HOME=/var/solr/data ---- -The `SOLR_PID_DIR` variable sets the directory where the <> will write out a file containing the Solr server’s process ID. +The `SOLR_PID_DIR` variable sets the directory where the <> will write out a file containing the Solr server’s process ID. ==== Log Settings @@ -115,7 +115,7 @@ LOG4J_PROPS=/var/solr/log4j2.xml SOLR_LOGS_DIR=/var/solr/logs ---- -For more information about Log4J configuration, please see: <> +For more information about Log4J configuration, please see: <> ==== init.d Script @@ -185,11 +185,11 @@ SOLR_HEAP="8g" Do not allocate a very large Java Heap unless you know you need it. See <> for details. ==== -Also, the <> comes with a set of pre-configured Garbage First Garbage Collection settings that have shown to work well with Solr for a number of different workloads. +Also, the <> comes with a set of pre-configured Garbage First Garbage Collection settings that have shown to work well with Solr for a number of different workloads. However, these settings may not work well for your specific use of Solr. Consequently, you may need to change the GC settings, which should also be done with the `GC_TUNE` variable in the `/etc/default/solr.in.sh` include file. For more information about garbage collection settings refer to following articles: 1. https://cwiki.apache.org/confluence/display/solr/ShawnHeisey 2. https://www.oracle.com/technetwork/articles/java/g1gc-1984535.html -You can also refer to <> for tuning your memory and garbage collection settings. +You can also refer to <> for tuning your memory and garbage collection settings. ==== Out-of-Memory Shutdown Hook @@ -215,7 +215,7 @@ If you're using a ZooKeeper instance that is shared by other systems, it's recom ZK_HOST=zk1,zk2,zk3/solr ---- -Before using a chroot for the first time, you need to create the root path (znode) in ZooKeeper by using the <>. We can use the mkroot command for that: +Before using a chroot for the first time, you need to create the root path (znode) in ZooKeeper by using the <>. We can use the mkroot command for that: [source,bash] ---- @@ -224,7 +224,7 @@ bin/solr zk mkroot /solr -z : [NOTE] ==== -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 <> 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 <> for more info. ==== === Solr Hostname 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 030cc09b4f7..7f1c4d7074e 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 @@ -16,11 +16,11 @@ // specific language governing permissions and limitations // under the License. -The Extended DisMax (eDisMax) query parser is an improved version of the <>. +The Extended DisMax (eDisMax) query parser is an improved version of the <>. In addition to supporting all the DisMax query parser parameters, Extended Dismax: -* supports <> syntax such as (non-exhaustive list): +* supports <> syntax such as (non-exhaustive list): ** boolean operators such as AND (+, &&), OR (||), NOT (-). ** optionally treats lowercase "and" and "or" as "AND" and "OR" in Lucene syntax mode ** optionally allows embedded queries using other query parsers or functions diff --git a/solr/solr-ref-guide/src/the-query-elevation-component.adoc b/solr/solr-ref-guide/src/the-query-elevation-component.adoc index dc69a810928..f43a73a6ae4 100644 --- a/solr/solr-ref-guide/src/the-query-elevation-component.adoc +++ b/solr/solr-ref-guide/src/the-query-elevation-component.adoc @@ -18,7 +18,7 @@ The Query Elevation Component lets you configure the top results for a given query regardless of the normal Lucene scoring. -This is sometimes called "sponsored search", "editorial boosting", or "best bets." This component matches the user query text to a configured map of top results. The text can be any string or non-string IDs, as long as it's indexed. Although this component will work with any QueryParser, it makes the most sense to use with <> or <>. +This is sometimes called "sponsored search", "editorial boosting", or "best bets." This component matches the user query text to a configured map of top results. The text can be any string or non-string IDs, as long as it's indexed. Although this component will work with any QueryParser, it makes the most sense to use with <> or <>. The Query Elevation Component also supports distributed searching. @@ -157,7 +157,7 @@ You can force set `useConfiguredElevatedOrder` during runtime by supplying it as === Document Transformers and the markExcludes Parameter -The `[elevated]` <> can be used to annotate each document with information about whether or not it was elevated: +The `[elevated]` <> can be used to annotate each document with information about whether or not it was elevated: [source,text] http://localhost:8983/solr/techproducts/elevate?q=ipod&df=text&fl=id,[elevated] diff --git a/solr/solr-ref-guide/src/the-standard-query-parser.adoc b/solr/solr-ref-guide/src/the-standard-query-parser.adoc index 2df5c9c3dbc..446026fd8a5 100644 --- a/solr/solr-ref-guide/src/the-standard-query-parser.adoc +++ b/solr/solr-ref-guide/src/the-standard-query-parser.adoc @@ -18,11 +18,11 @@ Solr's default Query Parser is also known as the "```lucene```" parser. -The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it's very intolerant of syntax errors, as compared with something like the <> query parser which is designed to throw as few errors as possible. +The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it's very intolerant of syntax errors, as compared with something like the <> query parser which is designed to throw as few errors as possible. == Standard Query Parser Parameters -In addition to the <>, <>, <>, and <>, the standard query parser supports the parameters described in the table below. +In addition to the <>, <>, <>, and <>, the standard query parser supports the parameters described in the table below. `q`:: Defines a query using standard query syntax. This parameter is mandatory. @@ -220,7 +220,7 @@ Example: == Querying Specific Fields -Data indexed in Solr is organized in fields, which are <>. Searches can take advantage of fields to add precision to queries. For example, you can search for a term only in a specific field, such as a title field. +Data indexed in Solr is organized in fields, which are <>. Searches can take advantage of fields to add precision to queries. For example, you can search for a term only in a specific field, such as a title field. The Schema defines one field as a default field. If you do not specify a field in a query, Solr searches only the default field. Alternatively, you can specify a different field or a combination of fields in a query. @@ -381,7 +381,7 @@ This can even be used to cache individual clauses of complex filter queries. In === Specifying Dates and Times -Queries against date based fields must use the <>. Queries for exact date values will require quoting or escaping since `:` is the parser syntax used to denote a field query: +Queries against date based fields must use the <>. Queries for exact date values will require quoting or escaping since `:` is the parser syntax used to denote a field query: * `createdate:1976-03-06T23\:59\:59.999Z` * `createdate:"1976-03-06T23:59:59.999Z"` diff --git a/solr/solr-ref-guide/src/the-stats-component.adoc b/solr/solr-ref-guide/src/the-stats-component.adoc index eedebe6c70d..0db83a0908b 100644 --- a/solr/solr-ref-guide/src/the-stats-component.adoc +++ b/solr/solr-ref-guide/src/the-stats-component.adoc @@ -35,7 +35,7 @@ If `true`, then invokes the Stats component. `stats.field`:: Specifies a field for which statistics should be generated. This parameter may be invoked multiple times in a query in order to request statistics on multiple fields. + -<> may be used to indicate which subset of the supported statistics should be computed, and/or that statistics should be computed over the results of an arbitrary numeric function (or query) instead of a simple field name. See the examples below. +<> may be used to indicate which subset of the supported statistics should be computed, and/or that statistics should be computed over the results of an arbitrary numeric function (or query) instead of a simple field name. See the examples below. === Stats Component Example @@ -134,7 +134,7 @@ This statistic is computed for all field types but is not computed by default. == Local Parameters with the Stats Component -Similar to the <>, the `stats.field` parameter supports local parameters for: +Similar to the <>, the `stats.field` parameter supports local parameters for: * Tagging & Excluding Filters: `stats.field={!ex=filterA}price` * Changing the Output Key: `stats.field={!key=my_price_stats}price` diff --git a/solr/solr-ref-guide/src/the-term-vector-component.adoc b/solr/solr-ref-guide/src/the-term-vector-component.adoc index 70073f0b620..3d88e3746af 100644 --- a/solr/solr-ref-guide/src/the-term-vector-component.adoc +++ b/solr/solr-ref-guide/src/the-term-vector-component.adoc @@ -162,7 +162,7 @@ This parameter requires both `tv.tf` and `tv.df` to be "true". This can be compu To see an example of TermVector component output, see the Wiki page: https://cwiki.apache.org/confluence/display/solr/TermVectorComponentExampleOptions -For schema requirements, see also the section <>. +For schema requirements, see also the section <>. == SolrJ and the Term Vector Component diff --git a/solr/solr-ref-guide/src/the-terms-component.adoc b/solr/solr-ref-guide/src/the-terms-component.adoc index cf27d2224e0..4cfc848eff7 100644 --- a/solr/solr-ref-guide/src/the-terms-component.adoc +++ b/solr/solr-ref-guide/src/the-terms-component.adoc @@ -298,7 +298,7 @@ Results (notice that the term counts are not affected by the query): == Using the Terms Component for an Auto-Suggest Feature -If the <> doesn't suit your needs, you can use the Terms component in Solr to build a similar feature for your own search application. Simply submit a query specifying whatever characters the user has typed so far as a prefix. For example, if the user has typed "at", the search engine's interface would submit the following query: +If the <> doesn't suit your needs, you can use the Terms component in Solr to build a similar feature for your own search application. Simply submit a query specifying whatever characters the user has typed so far as a prefix. For example, if the user has typed "at", the search engine's interface would submit the following query: [source,text] http://localhost:8983/solr/techproducts/terms?terms.fl=name&terms.prefix=at&wt=xml @@ -347,7 +347,7 @@ Result: The TermsComponent also supports distributed indexes. For the `/terms` request handler, you must provide the following two parameters: `shards`:: -Specifies the shards in your distributed indexing configuration. For more information about distributed indexing, see <>. +Specifies the shards in your distributed indexing configuration. For more information about distributed indexing, see <>. + The `shards` parameter is subject to a host whitelist that has to be configured in the component's parameters using the configuration key `shardsWhitelist` and the list of hosts as values. + diff --git a/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc b/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc index 546f2c6944e..87f5e0f662d 100644 --- a/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc +++ b/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc @@ -28,21 +28,21 @@ This section tells you how to fine-tune your Solr instance for optimum performan This section covers the following topics: -<>: Describes how to work with the main configuration file for Solr, `solrconfig.xml`, covering the major sections of the file. +<>: Describes how to work with the main configuration file for Solr, `solrconfig.xml`, covering the major sections of the file. -<>: Describes how to work with `solr.xml` and `core.properties` to configure your Solr core, or multiple Solr cores within a single instance. +<>: Describes how to work with `solr.xml` and `core.properties` to configure your Solr core, or multiple Solr cores within a single instance. -<>: Describes how word lists, model files, and other related data are resolved by the components that need them. +<>: Describes how word lists, model files, and other related data are resolved by the components that need them. -<>: Describes several APIs used to configure Solr: Blob Store, Config, Request Parameters and Managed Resources. +<>: Describes several APIs used to configure Solr: Blob Store, Config, Request Parameters and Managed Resources. -<>: Describes various end-points automatically provided by Solr and how to configure them. +<>: Describes various end-points automatically provided by Solr and how to configure them. -<>: Gives some guidance on best practices for working with Java Virtual Machines. +<>: Gives some guidance on best practices for working with Java Virtual Machines. -<>: Describes how to use the new V2 APIs, a redesigned API framework covering most Solr APIs. +<>: Describes how to use the new V2 APIs, a redesigned API framework covering most Solr APIs. [IMPORTANT] ==== -The focus of this section is generally on configuring a single Solr instance, but for those interested in scaling a Solr implementation in a cluster environment, see also the section <>. There are also options to scale through sharding or replication, described in the section <>. +The focus of this section is generally on configuring a single Solr instance, but for those interested in scaling a Solr implementation in a cluster environment, see also the section <>. There are also options to scale through sharding or replication, described in the section <>. ==== 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 c2fd06ece87..9bbea92e8c0 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 @@ -35,7 +35,7 @@ Provides multivalued mapping to map document field names to Solr field names. Th Wildcards can be used here, see <> below for more information. `mapUniqueKeyOnly`:: -(boolean) This parameter is particularly convenient when the fields in the input JSON are not available in the schema and <> is not enabled. This will index all the fields into the default search field (using the `df` parameter, below) and only the `uniqueKey` field is mapped to the corresponding field in the schema. If the input JSON does not have a value for the `uniqueKey` field then a UUID is generated for the same. +(boolean) This parameter is particularly convenient when the fields in the input JSON are not available in the schema and <> is not enabled. This will index all the fields into the default search field (using the `df` parameter, below) and only the `uniqueKey` field is mapped to the corresponding field in the schema. If the input JSON does not have a value for the `uniqueKey` field then a UUID is generated for the same. `df`:: If the `mapUniqueKeyOnly` flag is used, the update handler needs a field where the data should be indexed to. This is the same field that other handlers use as a default search field. @@ -276,12 +276,12 @@ In this example, we simply named the field paths (such as `/exams/test`). Solr w [TIP] ==== -Documents will be rejected during indexing if the fields do not exist in the schema before indexing. So, if you are NOT using schemaless mode, you must pre-create all fields. If you are working in <>, however, fields that don't exist will be created on the fly with Solr's best guess for the field type. +Documents will be rejected during indexing if the fields do not exist in the schema before indexing. So, if you are NOT using schemaless mode, you must pre-create all fields. If you are working in <>, however, fields that don't exist will be created on the fly with Solr's best guess for the field type. ==== === Reusing Parameters in Multiple Requests -You can store and re-use parameters with Solr's <>. +You can store and re-use parameters with Solr's <>. Say we wanted to define parameters to split documents at the `exams` field, and map several other fields. We could make an API request such as: diff --git a/solr/solr-ref-guide/src/transforming-result-documents.adoc b/solr/solr-ref-guide/src/transforming-result-documents.adoc index e1f2c5b42eb..f2859afab80 100644 --- a/solr/solr-ref-guide/src/transforming-result-documents.adoc +++ b/solr/solr-ref-guide/src/transforming-result-documents.adoc @@ -125,7 +125,7 @@ A default style can be configured by specifying an `args` parameter in your `sol === [child] - ChildDocTransformerFactory -This transformer returns all <> of each parent document matching your query. This is useful when you have indexed nested child documents and want to retrieve the child documents for the relevant parent documents for any type of search query. +This transformer returns all <> of each parent document matching your query. This is useful when you have indexed nested child documents and want to retrieve the child documents for the relevant parent documents for any type of search query. Note that this transformer can be used even when the query used to match the result documents is not a <>. @@ -198,7 +198,7 @@ DocIdAugmenterFactory does not support any request parameters, or configuration === [elevated] and [excluded] -These transformers are available only when using the <>. +These transformers are available only when using the <>. * `[elevated]` annotates each document to indicate if it was elevated or not. * `[excluded]` annotates each document to indicate if it would have been excluded - this is only supported if you also use the `markExcludes` parameter. @@ -351,14 +351,14 @@ Otherwise you'll get `NullPointerException` from `QueryComponent.mergeIds`. Formats spatial data from a spatial field using a designated format type name. Two inner parameters are required: `f` for the field name, and `w` for the format name. Example: `geojson:[geo f=mySpatialField w=GeoJSON]`. -Normally you'll simply be consistent in choosing the format type you want by setting the `format` attribute on the spatial field type to `WKT` or `GeoJSON` – see the section <> for more information. If you are consistent, it'll come out the way you stored it. This transformer offers a convenience to transform the spatial format to something different on retrieval. +Normally you'll simply be consistent in choosing the format type you want by setting the `format` attribute on the spatial field type to `WKT` or `GeoJSON` – see the section <> for more information. If you are consistent, it'll come out the way you stored it. This transformer offers a convenience to transform the spatial format to something different on retrieval. In addition, this feature is very useful with the `RptWithGeometrySpatialField` to avoid double-storage of the potentially large vector geometry. This transformer will detect that field type and fetch the geometry from an internal compact binary representation on disk (in docValues), and then format it as desired. As such, you needn't mark the field as stored, which would be redundant. In a sense this double-storage between docValues and stored-value storage isn't unique to spatial but with polygonal geometry it can be a lot of data, and furthermore you'd like to avoid storing it in a verbose format (like GeoJSON or WKT). === [features] - LTRFeatureLoggerTransformerFactory -The "LTR" prefix stands for <>. This transformer returns the values of features and it can be used for feature extraction and feature logging. +The "LTR" prefix stands for <>. This transformer returns the values of features and it can be used for feature extraction and feature logging. [source,plain] ---- diff --git a/solr/solr-ref-guide/src/understanding-analyzers-tokenizers-and-filters.adoc b/solr/solr-ref-guide/src/understanding-analyzers-tokenizers-and-filters.adoc index 7d379438158..dc603f7a58c 100644 --- a/solr/solr-ref-guide/src/understanding-analyzers-tokenizers-and-filters.adoc +++ b/solr/solr-ref-guide/src/understanding-analyzers-tokenizers-and-filters.adoc @@ -19,9 +19,9 @@ The following sections describe how Solr breaks down and works with textual data. There are three main concepts to understand: analyzers, tokenizers, and filters. -* <> are used both during ingestion, when a document is indexed, and at query time. An analyzer examines the text of fields and generates a token stream. Analyzers may be a single class or they may be composed of a series of tokenizer and filter classes. -* <> break field data into lexical units, or _tokens_. -* <> examine a stream of tokens and keep them, transform or discard them, or create new ones. Tokenizers and filters may be combined to form pipelines, or _chains_, where the output of one is input to the next. Such a sequence of tokenizers and filters is called an _analyzer_ and the resulting output of an analyzer is used to match query results or build indices. +* <> are used both during ingestion, when a document is indexed, and at query time. An analyzer examines the text of fields and generates a token stream. Analyzers may be a single class or they may be composed of a series of tokenizer and filter classes. +* <> break field data into lexical units, or _tokens_. +* <> examine a stream of tokens and keep them, transform or discard them, or create new ones. Tokenizers and filters may be combined to form pipelines, or _chains_, where the output of one is input to the next. Such a sequence of tokenizers and filters is called an _analyzer_ and the resulting output of an analyzer is used to match query results or build indices. == Using Analyzers, Tokenizers, and Filters @@ -35,20 +35,20 @@ These sections will show you how to configure field analyzers and also serves as *For Analyzers, see:* -* <>: Detailed conceptual information about Solr analyzers. -* <>: Detailed information about testing and running your Solr analyzer. +* <>: Detailed conceptual information about Solr analyzers. +* <>: Detailed information about testing and running your Solr analyzer. *For Tokenizers, see:* -* <>: Detailed conceptual information about Solr tokenizers. -* <>: Information about configuring tokenizers, and about the tokenizer factory classes included in this distribution of Solr. +* <>: Detailed conceptual information about Solr tokenizers. +* <>: Information about configuring tokenizers, and about the tokenizer factory classes included in this distribution of Solr. *For Filters, see:* -* <>: Detailed conceptual information about Solr filters. -* <>: Information about configuring filters, and about the filter factory classes included in this distribution of Solr. -* <>: Information about filters for pre-processing input characters. +* <>: Detailed conceptual information about Solr filters. +* <>: Information about configuring filters, and about the filter factory classes included in this distribution of Solr. +* <>: Information about filters for pre-processing input characters. *To find out how to use Tokenizers and Filters with various languages, see:* -* <>: Information about tokenizers and filters for character set conversion or for use with specific languages. +* <>: Information about tokenizers and filters for character set conversion or for use with specific languages. diff --git a/solr/solr-ref-guide/src/update-request-processors.adoc b/solr/solr-ref-guide/src/update-request-processors.adoc index aeee353a197..6f13f4329f6 100644 --- a/solr/solr-ref-guide/src/update-request-processors.adoc +++ b/solr/solr-ref-guide/src/update-request-processors.adoc @@ -112,7 +112,7 @@ In a single node, stand-alone Solr, each update is run through all the update pr A critical SolrCloud functionality is the routing and distributing of requests. For update requests this routing is implemented by the `DistributedUpdateRequestProcessor`, and this processor is given a special status by Solr due to its important function. -In SolrCloud mode, all processors in the chain _before_ the `DistributedUpdateProcessor` are run on the first node that receives an update from the client, regardless of this node's status as a leader or replica. The `DistributedUpdateProcessor` then forwards the update to the appropriate shard leader for the update (or to multiple leaders in the event of an update that affects multiple documents, such as a delete by query or commit). The shard leader uses a transaction log to apply <> and then forwards the update to all of the shard replicas. The leader and each replica run all of the processors in the chain that are listed _after_ the `DistributedUpdateProcessor`. +In SolrCloud mode, all processors in the chain _before_ the `DistributedUpdateProcessor` are run on the first node that receives an update from the client, regardless of this node's status as a leader or replica. The `DistributedUpdateProcessor` then forwards the update to the appropriate shard leader for the update (or to multiple leaders in the event of an update that affects multiple documents, such as a delete by query or commit). The shard leader uses a transaction log to apply <> and then forwards the update to all of the shard replicas. The leader and each replica run all of the processors in the chain that are listed _after_ the `DistributedUpdateProcessor`. For example, consider the "dedupe" chain which we saw in a section above. Assume that a 3-node SolrCloud cluster exists where node A hosts the leader of shard1, node B hosts the leader of shard2 and node C hosts the replica of shard2. Assume that an update request is sent to node A which forwards the update to node B (because the update belongs to shard2) which then distributes the update to its replica node C. Let's see what happens at each node: @@ -140,14 +140,14 @@ However executing a processor only on the forwarding nodes is a great way of dis .Custom update chain post-processors may never be invoked on a recovering replica [WARNING] ==== -While a replica is in <>, inbound update requests are buffered to the transaction log. After recovery has completed successfully, those buffered update requests are replayed. As of this writing, however, custom update chain post-processors are never invoked for buffered update requests. See https://issues.apache.org/jira/browse/SOLR-8030[SOLR-8030]. To work around this problem until SOLR-8030 has been fixed, *avoid specifying post-processors in custom update chains*. +While a replica is in <>, inbound update requests are buffered to the transaction log. After recovery has completed successfully, those buffered update requests are replayed. As of this writing, however, custom update chain post-processors are never invoked for buffered update requests. See https://issues.apache.org/jira/browse/SOLR-8030[SOLR-8030]. To work around this problem until SOLR-8030 has been fixed, *avoid specifying post-processors in custom update chains*. ==== === Atomic Update Processor Factory If the `AtomicUpdateProcessorFactory` is in the update chain before the `DistributedUpdateProcessor`, the incoming document to the chain will be a partial document. -Because `DistributedUpdateProcessor` is responsible for processing <> into full documents on the leader node, this means that pre-processors which are executed only on the forwarding nodes can only operate on the partial document. If you have a processor which must process a full document then the only choice is to specify it as a post-processor. +Because `DistributedUpdateProcessor` is responsible for processing <> into full documents on the leader node, this means that pre-processors which are executed only on the forwarding nodes can only operate on the partial document. If you have a processor which must process a full document then the only choice is to specify it as a post-processor. == Using Custom Chains @@ -225,9 +225,9 @@ In the first example, Solr will dynamically create a chain which has "signature" We can also specify a custom chain to be used by default for all requests sent to specific update handlers instead of specifying the names in request parameters for each request. -This can be done by adding either "update.chain" or "processor" and "post-processor" as default parameter for a given path which can be done either via <> or by adding them in a <> which is supported by all request handlers. +This can be done by adding either "update.chain" or "processor" and "post-processor" as default parameter for a given path which can be done either via <> or by adding them in a <> which is supported by all request handlers. -The following is an `initParam` defined in the <> which applies a custom update chain to all request handlers starting with "/update/". +The following is an `initParam` defined in the <> which applies a custom update chain to all request handlers starting with "/update/". .Example initParams [source,xml] @@ -283,7 +283,7 @@ What follows are brief descriptions of the currently available update request pr {solr-javadocs}/core/org/apache/solr/update/processor/SignatureUpdateProcessorFactory.html[SignatureUpdateProcessorFactory]:: Uses a defined set of fields to generate a hash "signature" for the document. Useful for only indexing one copy of "similar" documents. -{solr-javadocs}/contrib/scripting/org/apache/solr/scripting/update/ScriptUpdateProcessorFactory.html[ScriptUpdateProcessorFactory]:: An processor that enables the use of update processors implemented as scripts. Learn more at the <> page. +{solr-javadocs}/contrib/scripting/org/apache/solr/scripting/update/ScriptUpdateProcessorFactory.html[ScriptUpdateProcessorFactory]:: An processor that enables the use of update processors implemented as scripts. Learn more at the <> page. {solr-javadocs}/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 <> below. diff --git a/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc b/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc index e7b651f9c37..a7afaee7d8a 100644 --- a/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc +++ b/solr/solr-ref-guide/src/updatehandlers-in-solrconfig.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -The settings in this section are configured in the `` element in `solrconfig.xml` and may affect the performance of index updates. These settings affect how updates are done internally. `` configurations do not affect the higher level configuration of <> that process client update requests. +The settings in this section are configured in the `` element in `solrconfig.xml` and may affect the performance of index updates. These settings affect how updates are done internally. `` configurations do not affect the higher level configuration of <> that process client update requests. [source,xml] ---- @@ -33,9 +33,9 @@ Data sent to Solr is not searchable until it has been _committed_ to the index. In Solr, a `commit` is an action which asks Solr to "commit" those changes to the Lucene index files. By default commit actions result in a "hard commit" of all the Lucene index files to stable storage (disk). When a client includes a `commit=true` parameter with an update request, this ensures that all index segments affected by the adds & deletes on an update are written to disk as soon as index updates are completed. -If an additional flag `softCommit=true` is specified, then Solr performs a 'soft commit', meaning that Solr will commit your changes to the Lucene data structures quickly but not guarantee that the Lucene index files are written to stable storage. This is an implementation of Near Real Time storage, a feature that boosts document visibility, since you don't have to wait for background merges and storage (to ZooKeeper, if using <>) to finish before moving on to something else. A full commit means that, if a server crashes, Solr will know exactly where your data was stored; a soft commit means that the data is stored, but the location information isn't yet stored. The tradeoff is that a soft commit gives you faster visibility because it's not waiting for background merges to finish. +If an additional flag `softCommit=true` is specified, then Solr performs a 'soft commit', meaning that Solr will commit your changes to the Lucene data structures quickly but not guarantee that the Lucene index files are written to stable storage. This is an implementation of Near Real Time storage, a feature that boosts document visibility, since you don't have to wait for background merges and storage (to ZooKeeper, if using <>) to finish before moving on to something else. A full commit means that, if a server crashes, Solr will know exactly where your data was stored; a soft commit means that the data is stored, but the location information isn't yet stored. The tradeoff is that a soft commit gives you faster visibility because it's not waiting for background merges to finish. -For more information about Near Real Time operations, see <>. +For more information about Near Real Time operations, see <>. === autoCommit @@ -78,7 +78,7 @@ You can also specify 'soft' autoCommits in the same way that you can specify 'so === commitWithin -The `commitWithin` settings allow forcing document commits to happen in a defined time period. This is used most frequently with <>, and for that reason the default is to perform a soft commit. This does not, however, replicate new documents to follower servers in a leader/follower environment. If that's a requirement for your implementation, you can force a hard commit by adding a parameter, as in this example: +The `commitWithin` settings allow forcing document commits to happen in a defined time period. This is used most frequently with <>, and for that reason the default is to perform a soft commit. This does not, however, replicate new documents to follower servers in a leader/follower environment. If that's a requirement for your implementation, you can force a hard commit by adding a parameter, as in this example: [source,xml] ---- @@ -98,7 +98,7 @@ Users can write custom update event listener classes in Solr plugins. As of Solr == Transaction Log -As described in the section <>, a transaction log is required for that feature. It is configured in the `updateHandler` section of `solrconfig.xml`. +As described in the section <>, a transaction log is required for that feature. It is configured in the `updateHandler` section of `solrconfig.xml`. Realtime Get currently relies on the update log feature, which is enabled by default. It relies on an update log, which is configured in `solrconfig.xml`, in a section like: @@ -109,7 +109,7 @@ Realtime Get currently relies on the update log feature, which is enabled by def ---- -Three additional expert-level configuration settings affect indexing performance and how far a replica can fall behind on updates before it must enter into full recovery - see the section on <> for more information: +Three additional expert-level configuration settings affect indexing performance and how far a replica can fall behind on updates before it must enter into full recovery - see the section on <> for more information: `numRecordsToKeep`:: The number of update records to keep per log. The default is `100`. diff --git a/solr/solr-ref-guide/src/updating-parts-of-documents.adoc b/solr/solr-ref-guide/src/updating-parts-of-documents.adoc index b74a8eeb29d..9056db9f5bf 100644 --- a/solr/solr-ref-guide/src/updating-parts-of-documents.adoc +++ b/solr/solr-ref-guide/src/updating-parts-of-documents.adoc @@ -296,7 +296,7 @@ When documents are added/updated in batches even a single version conflict may l If the document being updated does not include the `\_version_` field, and atomic updates are not being used, the document will be treated by normal Solr rules, which is usually to discard the previous version. -When using Optimistic Concurrency, clients can include an optional `versions=true` request parameter to indicate that the _new_ versions of the documents being added should be included in the response. This allows clients to immediately know what the `\_version_` is of every document added without needing to make a redundant <>. +When using Optimistic Concurrency, clients can include an optional `versions=true` request parameter to indicate that the _new_ versions of the documents being added should be included in the response. This allows clients to immediately know what the `\_version_` is of every document added without needing to make a redundant <>. Following are some examples using `versions=true` in queries: diff --git a/solr/solr-ref-guide/src/upgrading-a-solr-cluster.adoc b/solr/solr-ref-guide/src/upgrading-a-solr-cluster.adoc index 6abe138e4bf..daefd7edb70 100644 --- a/solr/solr-ref-guide/src/upgrading-a-solr-cluster.adoc +++ b/solr/solr-ref-guide/src/upgrading-a-solr-cluster.adoc @@ -17,7 +17,7 @@ // specific language governing permissions and limitations // under the License. -This page covers how to upgrade an existing Solr cluster that was installed using the <>. +This page covers how to upgrade an existing Solr cluster that was installed using the <>. IMPORTANT: The steps outlined on this page assume you use the default service name of `solr`. If you use an alternate service name or Solr installation directory, some of the paths and commands mentioned below will have to be modified accordingly. @@ -25,9 +25,9 @@ IMPORTANT: The steps outlined on this page assume you use the default service na Here is a checklist of things you need to prepare before starting the upgrade process: -. Examine the <> to determine if any behavior changes in the new version of Solr will affect your installation. +. Examine the <> to determine if any behavior changes in the new version of Solr will affect your installation. . If not using replication (i.e., collections with `replicationFactor` less than 1), then you should make a backup of each collection. If all of your collections use replication, then you don't technically need to make a backup since you will be upgrading and verifying each node individually. -. Determine which Solr node is currently hosting the Overseer leader process in SolrCloud, as you should upgrade this node last. To determine the Overseer, use the Overseer Status API, see: <>. +. Determine which Solr node is currently hosting the Overseer leader process in SolrCloud, as you should upgrade this node last. To determine the Overseer, use the Overseer Status API, see: <>. . Plan to perform your upgrade during a system maintenance window if possible. You'll be doing a rolling restart of your cluster (each node, one-by-one), but we still recommend doing the upgrade when system usage is minimal. . Verify the cluster is currently healthy and all replicas are active, as you should not perform an upgrade on a degraded cluster. . Re-build and test all custom server-side components against the new Solr JAR files. @@ -35,7 +35,7 @@ Here is a checklist of things you need to prepare before starting the upgrade pr * `ZK_HOST`: The ZooKeeper connection string your current SolrCloud nodes use to connect to ZooKeeper; this value will be the same for all nodes in the cluster. * `SOLR_HOST`: The hostname each Solr node used to register with ZooKeeper when joining the SolrCloud cluster; this value will be used to set the *host* Java system property when starting the new Solr process. * `SOLR_PORT`: The port each Solr node is listening on, such as 8983. -* `SOLR_HOME`: The absolute path to the Solr home directory for each Solr node; this directory must contain a `solr.xml` file. This value will be passed to the new Solr process using the `solr.solr.home` system property, see: <>. +* `SOLR_HOME`: The absolute path to the Solr home directory for each Solr node; this directory must contain a `solr.xml` file. This value will be passed to the new Solr process using the `solr.solr.home` system property, see: <>. + If you are upgrading from an installation of Solr 5.x or later, these values can typically be found in either `/var/solr/solr.in.sh` or `/etc/default/solr.in.sh`. @@ -48,12 +48,12 @@ The approach we recommend is to perform the upgrade of each Solr node, one-by-on === Step 1: Stop Solr -Begin by stopping the Solr node you want to upgrade. After stopping the node, if using a replication (i.e., collections with `replicationFactor` less than 1), verify that all leaders hosted on the downed node have successfully migrated to other replicas; you can do this by visiting the <>. If not using replication, then any collections with shards hosted on the downed node will be temporarily off-line. +Begin by stopping the Solr node you want to upgrade. After stopping the node, if using a replication (i.e., collections with `replicationFactor` less than 1), verify that all leaders hosted on the downed node have successfully migrated to other replicas; you can do this by visiting the <>. If not using replication, then any collections with shards hosted on the downed node will be temporarily off-line. === Step 2: Install Solr as a Service -Please follow the instructions to install Solr as a Service on Linux documented at <>. Use the `-n` parameter to avoid automatic start of Solr by the installer script. You need to update the `/etc/default/solr.in.sh` include file in the next step to complete the upgrade process. +Please follow the instructions to install Solr as a Service on Linux documented at <>. Use the `-n` parameter to avoid automatic start of Solr by the installer script. You need to update the `/etc/default/solr.in.sh` include file in the next step to complete the upgrade process. [NOTE] ==== diff --git a/solr/solr-ref-guide/src/uploading-data-with-index-handlers.adoc b/solr/solr-ref-guide/src/uploading-data-with-index-handlers.adoc index 920240044f2..0d0ed7bd2d7 100644 --- a/solr/solr-ref-guide/src/uploading-data-with-index-handlers.adoc +++ b/solr/solr-ref-guide/src/uploading-data-with-index-handlers.adoc @@ -17,15 +17,15 @@ // specific language governing permissions and limitations // under the License. -Index Handlers are Request Handlers designed to add, delete and update documents to the index. In addition to having plugins for importing rich documents <>, Solr natively supports indexing structured documents in XML, CSV and JSON. +Index Handlers are Request Handlers designed to add, delete and update documents to the index. In addition to having plugins for importing rich documents <>, Solr natively supports indexing structured documents in XML, CSV and JSON. -The recommended way to configure and use request handlers is with path based names that map to paths in the request url. However, request handlers can also be specified with the `qt` (query type) parameter if the <> is appropriately configured. It is possible to access the same handler using more than one name, which can be useful if you wish to specify different sets of default options. +The recommended way to configure and use request handlers is with path based names that map to paths in the request url. However, request handlers can also be specified with the `qt` (query type) parameter if the <> is appropriately configured. It is possible to access the same handler using more than one name, which can be useful if you wish to specify different sets of default options. -A single unified update request handler supports XML, CSV, JSON, and javabin update requests, delegating to the appropriate `ContentStreamLoader` based on the `Content-Type` of the <>. +A single unified update request handler supports XML, CSV, JSON, and javabin update requests, delegating to the appropriate `ContentStreamLoader` based on the `Content-Type` of the <>. If you need to pre-process documents after they are loaded but before they are indexed (or even checked against the schema), Solr has document-preprocessing plugins for Update Request Handlers, -called <>, +called <>, which allow for default and custom configuration chains. == UpdateRequestHandler Configuration @@ -136,7 +136,7 @@ It doesn't work for child/nested docs. [IMPORTANT] ==== -When using the Join query parser in a Delete By Query, you should use the `score` parameter with a value of "none" to avoid a `ClassCastException`. See the section on the <> for more details on the `score` parameter. +When using the Join query parser in a Delete By Query, you should use the `score` parameter with a value of "none" to avoid a `ClassCastException`. See the section on the <> for more details on the `score` parameter. ==== @@ -220,7 +220,7 @@ The status field will be non-zero in case of failure. === Using XSLT to Transform XML Index Updates -The UpdateRequestHandler allows you to index any arbitrary XML using the `` parameter to apply an https://en.wikipedia.org/wiki/XSLT[XSL transformation]. You must have an XSLT stylesheet in the `conf/xslt` directory of your <> that can transform the incoming data to the expected `` format, and use the `tr` parameter to specify the name of that stylesheet. +The UpdateRequestHandler allows you to index any arbitrary XML using the `` parameter to apply an https://en.wikipedia.org/wiki/XSLT[XSL transformation]. You must have an XSLT stylesheet in the `conf/xslt` directory of your <> that can transform the incoming data to the expected `` format, and use the `tr` parameter to specify the name of that stylesheet. Here is an example XSLT stylesheet: @@ -280,7 +280,7 @@ curl "http://localhost:8983/solr/my_collection/update?commit=true&tr=updateXml.x == JSON Formatted Index Updates -Solr can accept JSON that conforms to a defined structure, or can accept arbitrary JSON-formatted documents. If sending arbitrarily formatted JSON, there are some additional parameters that need to be sent with the update request, described below in the section <>. +Solr can accept JSON that conforms to a defined structure, or can accept arbitrary JSON-formatted documents. If sending arbitrarily formatted JSON, there are some additional parameters that need to be sent with the update request, described below in the section <>. === Solr-Style JSON @@ -419,7 +419,7 @@ The `/update/json` path may be useful for clients sending in JSON formatted upda === Custom JSON Documents -Solr can support custom JSON. This is covered in the section <>. +Solr can support custom JSON. This is covered in the section <>. == CSV Formatted Index Updates diff --git a/solr/solr-ref-guide/src/uploading-data-with-solr-cell-using-apache-tika.adoc b/solr/solr-ref-guide/src/uploading-data-with-solr-cell-using-apache-tika.adoc index b4b9e17785c..80eda99ab23 100644 --- a/solr/solr-ref-guide/src/uploading-data-with-solr-cell-using-apache-tika.adoc +++ b/solr/solr-ref-guide/src/uploading-data-with-solr-cell-using-apache-tika.adoc @@ -44,7 +44,7 @@ You can configure which elements should be included/ignored, and which should ma * Solr Cell maps each piece of metadata onto a field. By default it maps to the same name but several parameters control how this is done. * When Solr Cell finishes creating the internal `SolrInputDocument`, the rest of the Lucene/Solr indexing stack takes over. -The next step after any update handler is the <> chain. +The next step after any update handler is the <> chain. Solr Cell is a contrib, which means it's not automatically included with Solr but must be configured. The example configsets have Solr Cell configured, but if you are not using those, @@ -70,7 +70,7 @@ that have a lot of rich media embedded in them. For these reasons, Solr Cell is not recommended for use in a production system. It is a best practice to use Solr Cell as a proof-of-concept tool during development and then run Tika as an external -process that sends the extracted documents to Solr (via <>) for indexing. +process that sends the extracted documents to Solr (via <>) for indexing. This way, any extraction failures that occur are isolated from Solr itself and can be handled gracefully. For a few examples of how this could be done, see this blog post by Erick Erickson, https://lucidworks.com/2012/02/14/indexing-with-solrj/[Indexing with SolrJ]. @@ -272,7 +272,7 @@ Also see the section <> for an example. === Configuring the ExtractingRequestHandler in solrconfig.xml -If you have started Solr with one of the supplied <>, you already have +If you have started Solr with one of the supplied <>, you already have the `ExtractingRequestHandler` configured by default and you only need to customize it for your content. If you are not working with an example configset, the jars required to use Solr Cell will not be loaded automatically. @@ -303,10 +303,10 @@ In this setup, all field names are lower-cased (with the `lowernames` parameter) [TIP] ==== -You may need to configure <> (URPs) +You may need to configure <> (URPs) that parse numbers and dates and do other manipulations on the metadata fields generated by Solr Cell. -In Solr's default configsets, <> (aka data driven, or field guessing) mode is enabled, which does a variety of such processing already. +In Solr's default configsets, <> (aka data driven, or field guessing) mode is enabled, which does a variety of such processing already. If you instead explicitly define the fields for your schema, you can selectively specify the desired URPs. An easy way to specify this is to configure the parameter `processor` (under `defaults`) to `uuid,remove-blank,field-name-mutating,parse-boolean,parse-long,parse-double,parse-date`. For example: @@ -365,7 +365,7 @@ myFileName = myPassword For a multi-core configuration, you can specify `sharedLib='lib'` in the `` section of `solr.xml` and place the necessary jar files there. -For more information about Solr cores, see <>. +For more information about Solr cores, see <>. === Extending the ExtractingRequestHandler @@ -466,7 +466,7 @@ curl "http://localhost:8983/solr/gettingstarted/update/extract?literal.id=doc6&d == Using Solr Cell with SolrJ -SolrJ is a Java client that you can use to add documents to the index, update the index, or query the index. You'll find more information on SolrJ in <>. +SolrJ is a Java client that you can use to add documents to the index, update the index, or query the index. You'll find more information on SolrJ in <>. Here's an example of using Solr Cell and SolrJ to add documents to a Solr index. diff --git a/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc b/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc index e764ed8c656..70555182a3b 100644 --- a/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc +++ b/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc @@ -19,27 +19,27 @@ This section discusses the Solr Administration User Interface ("Admin UI"). -The <> explains the basic features of the user interface, what's on the initial Admin UI page, and how to configure the interface. In addition, there are pages describing each screen of the Admin UI: +The <> explains the basic features of the user interface, what's on the initial Admin UI page, and how to configure the interface. In addition, there are pages describing each screen of the Admin UI: -* *<>* shows recent messages logged by this Solr node and provides a way to change logging levels for specific classes. -* *<>* display information about nodes when running in SolrCloud mode. -* *<>* explains how to get management information about each core. -* *<>* shows the Java information about each core. -* *<>* lets you see detailed information about each thread, along with state information. +* *<>* shows recent messages logged by this Solr node and provides a way to change logging levels for specific classes. +* *<>* display information about nodes when running in SolrCloud mode. +* *<>* explains how to get management information about each core. +* *<>* shows the Java information about each core. +* *<>* lets you see detailed information about each thread, along with state information. -* *<>* is a section explaining additional screens available for each collection. +* *<>* is a section explaining additional screens available for each collection. // TODO: SOLR-10655 BEGIN: refactor this into a 'collection-screens-list.include.adoc' file for reuse -** <> - lets you analyze the data found in specific fields. -** <> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser. -** <> - shows the current core configuration files such as `solrconfig.xml`. -** <> - lets you submit a structured query about various elements of a core. -** <> - allows you to submit streaming expressions and see results and parsing explanations. -** <> - displays schema data in a browser window. +** <> - lets you analyze the data found in specific fields. +** <> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser. +** <> - shows the current core configuration files such as `solrconfig.xml`. +** <> - lets you submit a structured query about various elements of a core. +** <> - allows you to submit streaming expressions and see results and parsing explanations. +** <> - displays schema data in a browser window. // TODO: SOLR-10655 END -* *<>* is a section explaining additional screens available for each named core. +* *<>* is a section explaining additional screens available for each named core. // TODO: SOLR-10655 BEGIN: refactor this into a 'core-screens-list.include.adoc' file for reuse -** <> - lets you ping a named core and determine whether the core is active. +** <> - lets you ping a named core and determine whether the core is active. ** <> - shows statistics for plugins and other installed components. -** <> - shows you the current replication status for the core, and lets you enable/disable replication. -** <> - Provides a visualization of the underlying Lucene index segments. +** <> - shows you the current replication status for the core, and lets you enable/disable replication. +** <> - Provides a visualization of the underlying Lucene index segments. // TODO: SOLR-10655 END diff --git a/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc b/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc index ee60018e21b..44c103a59f7 100644 --- a/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc +++ b/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc @@ -44,16 +44,16 @@ You can also explicitly upload a configuration directory when creating a collect bin/solr create -c mycollection -d _default ---- -The create command will upload a copy of the `_default` configuration directory to ZooKeeper under `/configs/mycollection`. Refer to the <> page for more details about the create command for creating collections. +The create command will upload a copy of the `_default` configuration directory to ZooKeeper under `/configs/mycollection`. Refer to the <> page for more details about the create command for creating collections. -Once a configuration directory has been uploaded to ZooKeeper, you can update them using the <> +Once a configuration directory has been uploaded to ZooKeeper, you can update them using the <> IMPORTANT: It's a good idea to keep these files under version control. == Uploading Configuration Files using bin/solr or SolrJ -In production situations, <> can also be uploaded to ZooKeeper independent of collection creation using either Solr's <> or SolrJ. +In production situations, <> can also be uploaded to ZooKeeper independent of collection creation using either Solr's <> or SolrJ. The below command can be used to upload a new configset using the bin/solr script. diff --git a/solr/solr-ref-guide/src/working-with-currencies-and-exchange-rates.adoc b/solr/solr-ref-guide/src/working-with-currencies-and-exchange-rates.adoc index f9ffb4932d3..ba7c39a4cba 100644 --- a/solr/solr-ref-guide/src/working-with-currencies-and-exchange-rates.adoc +++ b/solr/solr-ref-guide/src/working-with-currencies-and-exchange-rates.adoc @@ -45,7 +45,7 @@ The `currency` field type is defined in `schema.xml`. This is the default config In this example, we have defined the name and class of the field type, and defined the `defaultCurrency` as "USD", for U.S. Dollars. We have also defined a `currencyConfig` to use a file called "currency.xml". This is a file of exchange rates between our default currency to other currencies. There is an alternate implementation that would allow regular downloading of currency data. See <> below for more. -Many of the example schemas that ship with Solr include a <> that uses this type, such as this example: +Many of the example schemas that ship with Solr include a <> that uses this type, such as this example: [source,xml] ---- diff --git a/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc b/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc index 06d2c0e2de0..49dacce226f 100644 --- a/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc +++ b/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc @@ -22,7 +22,7 @@ The `ExternalFileField` type makes it possible to specify the values for a field [IMPORTANT] ==== -External fields are not searchable. They can be used only for function queries or display. For more information on function queries, see the section on <>. +External fields are not searchable. They can be used only for function queries or display. For more information on function queries, see the section on <>. ==== The `ExternalFileField` type is handy for cases where you want to update a particular field in many documents more often than you want to update the rest of the documents. For example, suppose you have implemented a document rank based on the number of views. You might want to update the rank of all the documents daily or hourly, while the rest of the contents of the documents might be updated much less frequently. Without `ExternalFileField`, you would need to update each document just to change the rank. Using `ExternalFileField` is much more efficient because all document values for a particular field are stored in an external file that can be updated as frequently as you wish.