mirror of https://github.com/apache/lucene.git
Ref Guide: fix miscellaneous formatting issues/typos/etc.
This commit is contained in:
Steve Rowe
parent
3033229766
commit
c37b377438
|
|
@ -108,7 +108,7 @@ The `.der` files that are output from Step 2 should then be loaded to ZooKeeper
|
|||
|
||||
At the current time, you can only use the ZooKeeper `zkCli.sh` (or `zkCli.cmd` on Windows) script to issue these commands (the Solr version has the same name, but is not the same). If you have your own ZooKeeper ensemble running already, you can find the script in `$ZK_INSTALL/bin/zkCli.sh` (or `zkCli.cmd` if you are using Windows).
|
||||
|
||||
NOTE: If you are running the embedded ZooKeeper that is included with Solr, you *do not* have this script already; in order to use it, you will need to download a copy of ZooKeeper v3.4.6 from http://zookeeper.apache.org/. Don't worry about configuring the download, you're just trying to get the command line utility script. When you start the script, you will connect to the embedded ZooKeeper.
|
||||
NOTE: If you are running the embedded ZooKeeper that is included with Solr, you *do not* have this script already; in order to use it, you will need to download a copy of ZooKeeper v3.4.10 from http://zookeeper.apache.org/. Don't worry about configuring the download, you're just trying to get the command line utility script. When you start the script, you will connect to the embedded ZooKeeper.
|
||||
|
||||
To load the keys, you will need to connect to ZooKeeper with `zkCli.sh`, create the directories, and then create the key file, as in the following example.
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ The table below presents examples of HTML stripping.
|
|||
|`hello<script><!-- f('<!--internal--></script>'); --></script>` |hello
|
||||
|`if a<b then print a;` |if a<b then print a;
|
||||
|`hello <td height=22 nowrap align="left">` |hello
|
||||
|`a<b A Alpha&Omega Ω` |a<b A Alpha&Omega Ω
|
||||
|`a<b A Alpha&Omega` Ω |a<b A Alpha&Omega Ω
|
||||
|===
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
When running in <<solrcloud.adoc#solrcloud,SolrCloud>> mode, a "Cloud" option will appear in the Admin UI between <<logging.adoc#logging,Logging>> and <<collections-core-admin.adoc#collections-core-admin,Collections/Core Admin>>.
|
||||
|
||||
This screen provides status information about each collection & node in your cluster, as well as access to the low level data being stored in <<using-zookeeper-to-manage-configuration-files.adoc#using-zookeeper-to-manage-configuration-files,Zookeeper>>.
|
||||
This screen provides status information about each collection & node in your cluster, as well as access to the low level data being stored in <<using-zookeeper-to-manage-configuration-files.adoc#using-zookeeper-to-manage-configuration-files,ZooKeeper>>.
|
||||
|
||||
.Only Visible When using SolrCloud
|
||||
[NOTE]
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Example:
|
|||
|
||||
=== solr.SimpleTextCodecFactory
|
||||
|
||||
This factory for Lucene's {solr-javadocs}/solr-core/org/apache/solr/core/SimpleTextCodecFactory.html[`solr.SimpleTextCodecFactory`] produces a plain text human-readable index format.
|
||||
This factory for Lucene's {solr-javadocs}/solr-core/org/apache/solr/core/SimpleTextCodecFactory.html[`SimpleTextCodecFactory`] produces a plain text human-readable index format.
|
||||
|
||||
CAUTION: *FOR RECREATIONAL USE ONLY*. This codec should never be used in production. `SimpleTextCodec` is relatively slow and takes up a large amount of disk space. Its use should be limited to educational and debugging purposes.
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ http://localhost:8983/solr/admin/collections?action=CREATE&name=newCollection&nu
|
|||
|
||||
`/admin/collections?action=MODIFYCOLLECTION&collection=_<collection-name>&<attribute-name>=<attribute-value>&<another-attribute-name>=<another-value>_`
|
||||
|
||||
It's possible to edit multiple attributes at a time. Changing these values only updates the z-node on Zookeeper, they do not change the topology of the collection. For instance, increasing replicationFactor will _not_ automatically add more replicas to the collection but _will_ allow more ADDREPLICA commands to succeed.
|
||||
It's possible to edit multiple attributes at a time. Changing these values only updates the z-node on ZooKeeper, they do not change the topology of the collection. For instance, increasing replicationFactor will _not_ automatically add more replicas to the collection but _will_ allow more ADDREPLICA commands to succeed.
|
||||
|
||||
*Query Parameters*
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ This section will describe the default `solr.xml` file included with Solr and ho
|
|||
|
||||
== Defining solr.xml
|
||||
|
||||
You can find `solr.xml` in your `$SOLR_HOME` directory (usually `server/solr`) in standalone mode or in Zookeeper when using SolrCloud. The default `solr.xml` file looks like this:
|
||||
You can find `solr.xml` in your `$SOLR_HOME` directory (usually `server/solr`) in standalone mode or in ZooKeeper when using SolrCloud. The default `solr.xml` file looks like this:
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ For most SolrCloud or standalone Solr setups, the `HadoopAuthPlugin` should suff
|
|||
|authConfigs |Yes |Configuration parameters required by the authentication scheme defined by the type property. For more details, see https://hadoop.apache.org/docs/stable/hadoop-auth/Configuration.html[Hadoop configuration] options.
|
||||
|defaultConfigs |No |Default values for the configuration parameters specified by the `authConfigs` property. The default values are specified as a collection of key-value pairs (i.e., `property-name:default_value`).
|
||||
|enableDelegationToken |No |Enable (or disable) the delegation tokens functionality.
|
||||
|initKerberosZk |No |For enabling initialization of kerberos before connecting to Zookeeper (if applicable).
|
||||
|initKerberosZk |No |For enabling initialization of kerberos before connecting to ZooKeeper (if applicable).
|
||||
|proxyUserConfigs |No |Configures proxy users for the underlying Hadoop authentication mechanism. This configuration is expressed as a collection of key-value pairs (i.e., `property-name:value`).
|
||||
|clientBuilderFactory |No |The `HttpClientBuilderFactory` implementation used for the Solr internal communication. Only applicable for `ConfigurableInternodeAuthHadoopPlugin`.
|
||||
|===
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Solr ships with many out-of-the-box RequestHandlers, which are called implicit b
|
|||
|<<uploading-data-with-index-handlers.adoc#uploading-data-with-index-handlers,`/update`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE` |Add, delete and update indexed documents formatted as SolrXML, CSV, SolrJSON or javabin.
|
||||
|<<uploading-data-with-index-handlers.adoc#UploadingDatawithIndexHandlers-CSVUpdateConveniencePaths,`/update/csv`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_CSV` |Add and update CSV-formatted documents.
|
||||
|<<uploading-data-with-index-handlers.adoc#UploadingDatawithIndexHandlers-CSVUpdateConveniencePaths,`/update/json`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON` |Add, delete and update SolrJSON-formatted documents.
|
||||
|<<transforming-and-indexing-custom-json.adoc#transforming-and-indexing-custom-json,`/update/json/docs`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON_DOCS ` |Add and update custom JSON-formatted documents.
|
||||
|<<transforming-and-indexing-custom-json.adoc#transforming-and-indexing-custom-json,`/update/json/docs`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON_DOCS` |Add and update custom JSON-formatted documents.
|
||||
|===
|
||||
|
||||
[[ImplicitRequestHandlers-HowtoViewtheConfiguration]]
|
||||
|
|
|
|||
|
|
@ -59,11 +59,11 @@ Since a Solr cluster requires internode communication, each node must also be ab
|
|||
[[KerberosAuthenticationPlugin-KerberizedZooKeeper]]
|
||||
=== Kerberized ZooKeeper
|
||||
|
||||
When setting up a kerberized SolrCloud cluster, it is recommended to enable Kerberos security for Zookeeper as well.
|
||||
When setting up a kerberized SolrCloud cluster, it is recommended to enable Kerberos security for ZooKeeper as well.
|
||||
|
||||
In such a setup, the client principal used to authenticate requests with Zookeeper can be shared for internode communication as well. This has the benefit of not needing to renew the ticket granting tickets (TGTs) separately, since the Zookeeper client used by Solr takes care of this. To achieve this, a single JAAS configuration (with the app name as Client) can be used for the Kerberos plugin as well as for the Zookeeper client.
|
||||
In such a setup, the client principal used to authenticate requests with ZooKeeper can be shared for internode communication as well. This has the benefit of not needing to renew the ticket granting tickets (TGTs) separately, since the Zookeeper client used by Solr takes care of this. To achieve this, a single JAAS configuration (with the app name as Client) can be used for the Kerberos plugin as well as for the Zookeeper client.
|
||||
|
||||
See the <<ZooKeeper Configuration>> section below for an example of starting Zookeeper in Kerberos mode.
|
||||
See the <<ZooKeeper Configuration>> section below for an example of starting ZooKeeper in Kerberos mode.
|
||||
|
||||
[[KerberosAuthenticationPlugin-BrowserConfiguration]]
|
||||
=== Browser Configuration
|
||||
|
|
@ -126,7 +126,7 @@ kadmin.local: quit
|
|||
|
||||
Copy the keytab file from the KDC server’s `/tmp/107.keytab` location to the Solr host at `/keytabs/107.keytab`. Repeat this step for each Solr node.
|
||||
|
||||
You might need to take similar steps to create a Zookeeper service principal and keytab if it has not already been set up. In that case, the example below shows a different service principal for ZooKeeper, so the above might be repeated with `zookeeper/host1` as the service principal for one of the nodes
|
||||
You might need to take similar steps to create a ZooKeeper service principal and keytab if it has not already been set up. In that case, the example below shows a different service principal for ZooKeeper, so the above might be repeated with `zookeeper/host1` as the service principal for one of the nodes
|
||||
|
||||
[[KerberosAuthenticationPlugin-ZooKeeperConfiguration]]
|
||||
=== ZooKeeper Configuration
|
||||
|
|
@ -191,7 +191,7 @@ More details on how to use a `/security.json` file in Solr are available in the
|
|||
|
||||
[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 <<command-line-utilities.adoc#command-line-utilities,Command Line Utilities>> 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 <<command-line-utilities.adoc#command-line-utilities,Command Line Utilities>> available in Solr.
|
||||
====
|
||||
|
||||
[[KerberosAuthenticationPlugin-DefineaJAASConfigurationFile]]
|
||||
|
|
@ -201,7 +201,7 @@ The JAAS configuration file defines the properties to use for authentication, su
|
|||
|
||||
The following example can be copied and modified slightly for your environment. The location of the file can be anywhere on the server, but it will be referenced when starting Solr so it must be readable on the filesystem. The JAAS file may contain multiple sections for different users, but each section must have a unique name so it can be uniquely referenced in each application.
|
||||
|
||||
In the below example, we have created a JAAS configuration file with the name and path of `/home/foo/jaas-client.conf`. We will use this name and path when we define the Solr start parameters in the next section. Note that the client `principal` here is the same as the service principal. This will be used to authenticate internode requests and requests to Zookeeper. Make sure to use the correct `principal` hostname and the `keyTab` file path.
|
||||
In the below example, we have created a JAAS configuration file with the name and path of `/home/foo/jaas-client.conf`. We will use this name and path when we define the Solr start parameters in the next section. Note that the client `principal` here is the same as the service principal. This will be used to authenticate internode requests and requests to ZooKeeper. Make sure to use the correct `principal` hostname and the `keyTab` file path.
|
||||
|
||||
[source,plain]
|
||||
----
|
||||
|
|
@ -242,7 +242,7 @@ While starting up Solr, the following host-specific parameters need to be passed
|
|||
|`solr.kerberos.cookie.portaware` |No |When set to true, cookies are differentiated based on host and port, as opposed to standard cookies which are not port aware. This should be set if more than one Solr node is hosted on the same host. The default is false.
|
||||
|`solr.kerberos.principal` |Yes |The service principal.
|
||||
|`solr.kerberos.keytab` |Yes |Keytab file path containing service principal credentials.
|
||||
|`solr.kerberos.jaas.appname` |No |The app name (section name) within the JAAS configuration file which is required for internode communication. Default is `Client`, which is used for Zookeeper authentication as well. If different users are used for ZooKeeper and Solr, they will need to have separate sections in the JAAS configuration file.
|
||||
|`solr.kerberos.jaas.appname` |No |The app name (section name) within the JAAS configuration file which is required for internode communication. Default is `Client`, which is used for ZooKeeper authentication as well. If different users are used for ZooKeeper and Solr, they will need to have separate sections in the JAAS configuration file.
|
||||
|`java.security.auth.login.config` |Yes |Path to the JAAS configuration file for configuring a Solr client for internode communication.
|
||||
|===
|
||||
|
||||
|
|
|
|||
|
|
@ -239,7 +239,7 @@ The parallel SQL interface supports and pushes down most common SQL operators, s
|
|||
|> |Greater than |`fielda > 10` | `fielda:{10 TO *]`
|
||||
|>= |Greater than or equals |`fielda >= 10` | `fielda:[10 TO *]`
|
||||
|< |Less than |`fielda < 10` | `fielda:[* TO 10}`
|
||||
|<= |Less than or equals |`fielda <= 10` | `fielda:[* TO 10]`
|
||||
|\<= |Less than or equals |`fielda \<= 10` | `fielda:[* TO 10]`
|
||||
|===
|
||||
|
||||
Some operators that are not supported are BETWEEN, LIKE and IN. However, there are workarounds for BETWEEN and LIKE.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
This page explains some of the <<using-jmx-with-solr.adoc#using-jmx-with-solr,JMX>> statistics that Solr exposes.
|
||||
|
||||
The same statistics are also exposed via the<<mbean-request-handler.adoc#mbean-request-handler,MBean Request Handler>> when statistics are requested.
|
||||
The same statistics are also exposed via the <<mbean-request-handler.adoc#mbean-request-handler,MBean Request Handler>> when statistics are requested.
|
||||
|
||||
These statistics are per core. When you are running in SolrCloud mode these statistics would co-relate to each performance of an individual replica.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Shutting down a redundant Solr instance will also shut down its ZooKeeper server
|
|||
The solution to this problem is to set up an external ZooKeeper ensemble. Fortunately, while this process can seem intimidating due to the number of powerful options, setting up a simple ensemble is actually quite straightforward, as described below.
|
||||
|
||||
.How Many ZooKeepers?
|
||||
[quote,ZooKeeper Administrator's Guide,http://zookeeper.apache.org/doc/r3.4.6/zookeeperAdmin.html]
|
||||
[quote,ZooKeeper Administrator's Guide,http://zookeeper.apache.org/doc/r3.4.10/zookeeperAdmin.html]
|
||||
____
|
||||
"For a ZooKeeper service to be active, there must be a majority of non-failing machines that can communicate with each other. *To create a deployment that can tolerate the failure of F machines, you should count on deploying 2xF+1 machines*. Thus, a deployment that consists of three machines can handle one failure, and a deployment of five machines can handle two failures. Note that a deployment of six machines can only handle two failures since three machines is not a majority.
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ It is generally recommended to have an odd number of ZooKeeper servers in your e
|
|||
|
||||
For example, if you only have two ZooKeeper nodes and one goes down, 50% of available servers is not a majority, so ZooKeeper will no longer serve requests. However, if you have three ZooKeeper nodes and one goes down, you have 66% of available servers available, and ZooKeeper will continue normally while you repair the one down node. If you have 5 nodes, you could continue operating with two down nodes if necessary.
|
||||
|
||||
More information on ZooKeeper clusters is available from the ZooKeeper documentation at http://zookeeper.apache.org/doc/r3.4.6/zookeeperAdmin.html#sc_zkMulitServerSetup.
|
||||
More information on ZooKeeper clusters is available from the ZooKeeper documentation at http://zookeeper.apache.org/doc/r3.4.10/zookeeperAdmin.html#sc_zkMulitServerSetup.
|
||||
|
||||
[[SettingUpanExternalZooKeeperEnsemble-DownloadApacheZooKeeper]]
|
||||
== Download Apache ZooKeeper
|
||||
|
|
@ -49,7 +49,7 @@ The first step in setting up Apache ZooKeeper is, of course, to download the sof
|
|||
====
|
||||
When using stand-alone ZooKeeper, you need to take care to keep your version of ZooKeeper updated with the latest version distributed with Solr. Since you are using it as a stand-alone application, it does not get upgraded when you upgrade Solr.
|
||||
|
||||
Solr currently uses Apache ZooKeeper v3.4.6.
|
||||
Solr currently uses Apache ZooKeeper v3.4.10.
|
||||
====
|
||||
|
||||
[[SettingUpanExternalZooKeeperEnsemble-SettingUpaSingleZooKeeper]]
|
||||
|
|
@ -92,7 +92,7 @@ Again, ZooKeeper provides a great deal of power through additional configuration
|
|||
|
||||
Pointing Solr at the ZooKeeper instance you've created is a simple matter of using the `-z` parameter when using the bin/solr script. For example, in order to point the Solr instance to the ZooKeeper you've started on port 2181, this is what you'd need to do:
|
||||
|
||||
Starting `cloud` example with Zookeeper already running at port 2181 (with all other defaults):
|
||||
Starting `cloud` example with ZooKeeper already running at port 2181 (with all other defaults):
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Before SolrCloud, Solr supported Distributed Search, which allowed one query to
|
|||
|
||||
SolrCloud fixes all those problems. There is support for distributing both the index process and the queries automatically, and ZooKeeper provides failover and load balancing. Additionally, every shard can also have multiple replicas for additional robustness.
|
||||
|
||||
In SolrCloud there are no masters or slaves. Instead, every shard consists of at least one physical *replica*, exactly one of which is a *leader*. Leaders are automatically elected, initially on a first-come-first-served basis, and then based on the Zookeeper process described at http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection[http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection.].
|
||||
In SolrCloud there are no masters or slaves. Instead, every shard consists of at least one physical *replica*, exactly one of which is a *leader*. Leaders are automatically elected, initially on a first-come-first-served basis, and then based on the ZooKeeper process described at http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection[http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection.].
|
||||
|
||||
If a leader goes down, one of the other replicas is automatically elected as the new leader.
|
||||
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ Sets the solr.solr.home system property; Solr will create core directories under
|
|||
This parameter is ignored when running examples (-e), as the solr.solr.home depends on which example is run.
|
||||
|
||||
|`bin/solr start -s newHome`
|
||||
|-v |Be more verbose. This changes the logging level of log4j from `INFO` to `DEBUG`., having the same effect as if you edited `log4j.properties` accordingly. |`bin/solr start -f -v`
|
||||
|-v |Be more verbose. This changes the logging level of log4j from `INFO` to `DEBUG`, having the same effect as if you edited `log4j.properties` accordingly. |`bin/solr start -f -v`
|
||||
|-q |Be more quiet. This changes the logging level of log4j from `INFO` to `WARN`, having the same effect as if you edited `log4j.properties` accordingly. This can be useful in a production setting where you want to limit logging to warnings and errors. |`bin/solr start -f -q`
|
||||
|-V |Start Solr with verbose messages from the start script. |`bin/solr start -V`
|
||||
|-z <zkHost> |Start Solr with the defined ZooKeeper connection string. This option is only used with the -c option, to start Solr in SolrCloud mode. If this option is not provided, Solr will start the embedded ZooKeeper instance and use that instance for SolrCloud operations. |`bin/solr start -c -z server1:2181,server2:2181`
|
||||
|
|
@ -577,7 +577,11 @@ The path to write the downloaded configuration set into. If just a name is suppl
|
|||
|
||||
In either case, _pre-existing configurations at the destination will be overwritten!_
|
||||
|
||||
|`-d directory_under_configsets` `-d /path/to/configset/destination`
|
||||
a|
|
||||
`-d directory_under_configsets`
|
||||
|
||||
`-d /path/to/configset/destination`
|
||||
|
||||
|-z <zkHost> |The ZooKeeper connection string. Unnecessary if ZK_HOST is defined in `solr.in.sh` or `solr.in.cmd`. |`-z 123.321.23.43:2181`
|
||||
|===
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ In Solr, the term _core_ is used to refer to a single index and associated trans
|
|||
|
||||
Cores can be created using `bin/solr` script or as part of SolrCloud collection creation using the APIs. Core-specific properties (such as the directories to use for the indexes or configuration files, the core name, and other options) are defined in a `core.properties` file. Any `core.properties` file in any directory of your Solr installation (or in a directory under where `solr_home` is defined) will be found by Solr and the defined properties will be used for the core named in the file.
|
||||
|
||||
In standalone mode, `solr.xml` must reside in `solr_home`. In SolrCloud mode, `solr.xml` will be loaded from Zookeeper if it exists, with fallback to `solr_home`.
|
||||
In standalone mode, `solr.xml` must reside in `solr_home`. In SolrCloud mode, `solr.xml` will be loaded from ZooKeeper if it exists, with fallback to `solr_home`.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
|
|
|||
|
|
@ -335,7 +335,7 @@ The expressions below show the various ways in which you can use the `gt` evalua
|
|||
----
|
||||
gt(1,2) // 1 > 2
|
||||
gt(1,fieldA) // 1 > fieldA
|
||||
gt(fieldA,val(foo)) fieldA > "foo"
|
||||
gt(fieldA,val(foo)) // fieldA > "foo"
|
||||
gt(add(fieldA,fieldB),6) // fieldA + fieldB > 6
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ Request parameters can be substituted in configuration with placeholder `${datai
|
|||
<dataSource driver="org.hsqldb.jdbcDriver"
|
||||
url="${dataimporter.request.jdbcurl}"
|
||||
user="${dataimporter.request.jdbcuser}"
|
||||
password=${dataimporter.request.jdbcpassword} />
|
||||
password="${dataimporter.request.jdbcpassword}" />
|
||||
----
|
||||
|
||||
These parameters can then be passed to the `full-import` command or defined in the `<defaults>` section in `solrconfig.xml`. This example shows the parameters with the full-import command:
|
||||
|
|
|
|||
|
|
@ -53,7 +53,10 @@ As you can see, the date format includes colon characters separating the hours,
|
|||
|
||||
This is normally an invalid query: `datefield:1972-05-20T17:33:18.772Z`
|
||||
|
||||
These are valid queries: `datefield:1972-05-20T17\:33\:18.772Z` `datefield:"1972-05-20T17:33:18.772Z"` `datefield:[1972-05-20T17:33:18.772Z TO *]`
|
||||
These are valid queries: +
|
||||
`datefield:1972-05-20T17\:33\:18.772Z` +
|
||||
`datefield:"1972-05-20T17:33:18.772Z"` +
|
||||
`datefield:[1972-05-20T17:33:18.772Z TO *]`
|
||||
|
||||
====
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
// specific language governing permissions and limitations
|
||||
// under the License.
|
||||
|
||||
This section describes using ZooKeeper access control lists (ACLs) with Solr. For information about ZooKeeper ACLs, see the ZooKeeper documentation at http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#sc_ZooKeeperAccessControl.
|
||||
This section describes using ZooKeeper access control lists (ACLs) with Solr. For information about ZooKeeper ACLs, see the ZooKeeper documentation at http://zookeeper.apache.org/doc/r3.4.10/zookeeperProgrammers.html#sc_ZooKeeperAccessControl.
|
||||
|
||||
[[ZooKeeperAccessControl-AboutZooKeeperACLs]]
|
||||
== About ZooKeeper ACLs
|
||||
|
|
|
|||
Loading…
Reference in New Issue