You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2019/04/06 13:10:51 UTC

[lucene-solr] branch master updated: Ref Guide: fix numbered list to resolve build warnings

This is an automated email from the ASF dual-hosted git repository.

ctargett pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git


The following commit(s) were added to refs/heads/master by this push:
     new ef7be67  Ref Guide: fix numbered list to resolve build warnings
ef7be67 is described below

commit ef7be67ba12c8f518591b1e6ec7c1d88e0834dc1
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Sat Apr 6 06:45:21 2019 -0500

    Ref Guide: fix numbered list to resolve build warnings
---
 solr/solr-ref-guide/src/aliases.adoc | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/solr/solr-ref-guide/src/aliases.adoc b/solr/solr-ref-guide/src/aliases.adoc
index 52ce75d..610530e 100644
--- a/solr/solr-ref-guide/src/aliases.adoc
+++ b/solr/solr-ref-guide/src/aliases.adoc
@@ -21,9 +21,9 @@
 Since version 6, SolrCloud has had the ability to query one or more collections via an alternative name. These
 alternative names for collections are known as aliases, and are useful when you want to:
 
-1. Atomically switch to using a newly (re)indexed collection with zero down time (by re-defining the alias)
-1. Insulate the client programming versus changes in collection names
-1. Issue a single query against several collections with identical schemas
+. Atomically switch to using a newly (re)indexed collection with zero down time (by re-defining the alias)
+. Insulate the client programming versus changes in collection names
+. Issue a single query against several collections with identical schemas
 
 It's also possible to send update commands to aliases, but this is rarely useful if the
   alias refers to more than one collection (as in case 3 above).
@@ -219,10 +219,10 @@ Unlike time routed aliases, there is no way to predict the next value so such pa
 There is no automated means of removing a category. If a category needs to be removed from a CRA
 the following procedure is recommended:
 
-1. Ensure that no documents with the value corresponding to the category to be removed will be sent
+. Ensure that no documents with the value corresponding to the category to be removed will be sent
    either by stopping indexing or by fixing the incoming data stream
-1. Modify the alias definition in zookeeper, removing the collection corresponding to the category.
-1. Delete the collection corresponding to the category. Note that if the collection is not removed
+. Modify the alias definition in zookeeper, removing the collection corresponding to the category.
+. Delete the collection corresponding to the category. Note that if the collection is not removed
    from the alias first, this step will fail.
 
 === Limitations & Assumptions
@@ -264,4 +264,4 @@ Some _potential_ areas for improvement that _are not implemented yet_ are:
 * Option for deletion of aliases that also deletes the underlying collections in one step. Routed Aliases may quickly
   create more collections than expected during initial testing. Removing them after such events is overly tedious.
 
-As always, patches and pull requests are welcome!
\ No newline at end of file
+As always, patches and pull requests are welcome!