Merge remote-tracking branch 'origin/ellen_troutman-atmr29208100074'

050_Search/20_Query_string.asciidoc

@@ -60,7 +60,7 @@ How has Elasticsearch managed to find results in three different fields?
 
 When you index a document, Elasticsearch takes the string values of all of
 its fields and concatenates them into one big string, which it indexes as
-the special `_all` field.((("all field"))) For example, when we index this document:
+the special `_all` field.((("_all field", sortas="all field"))) For example, when we index this document:
 
 [source,js]
 --------------------------------------------------

054_Query_DSL/70_Important_clauses.asciidoc

@@ -148,7 +148,7 @@ the search:
 --------------------------------------------------
 // SENSE: 054_Query_DSL/70_Match_query.json
 
-If you use it on a field containing an exact value, such as a number, a date,
+If you use it on a field containing an exact value, ((("exact values", "searching for, match queries and")))such as a number, a date,
 a Boolean, or a `not_analyzed` string field, then it will search for that
 exact value:
 

054_Query_DSL/75_Queries_with_filters.asciidoc

@@ -1,7 +1,7 @@
 === Combining Queries with Filters
 
 Queries can be used in _query context_, and filters can be used
-in _filter context_.  Throughout the Elasticsearch API, you will see parameters
+in _filter context_. ((("filters", "combining with queries")))((("queries", "combining with filters"))) Throughout the Elasticsearch API, you will see parameters
 with `query` or `filter` in the name.  These
 expect a single argument containing either a single query or filter clause
 respectively. In other words, they establish the
@@ -19,7 +19,7 @@ to achieve your goal in the most efficient way.
 [[filtered-query]]
 ==== Filtering a Query
 
-Let's say we have this query:
+Let's say we have((("filters", "combining with queries", "filtering a query"))) this query:
 
 [source,js]
 --------------------------------------------------
@@ -69,7 +69,7 @@ GET /_search
 [role="pagebreak-before"]
 ==== Just a Filter
 
-While in query context, if you need to use a filter without a query (for
+While in query context, if ((("filters", "combining with queries", "using just a filter in query context")))you need to use a filter without a query (for
 instance, to match all emails in the inbox), you can just omit the
 query:
 
@@ -107,7 +107,7 @@ GET /_search
 ==== A Query as a Filter
 
 Occasionally, you will want to use a query while you are in filter context.
-This can be achieved with the `query` filter, which just wraps a query. The following 
+This can be achieved with the `query` filter, which ((("filters", "combining with queries", "query as a filter")))((("queries", "combining with filters", "query filter")))just wraps a query. The following 
 example shows one way we could exclude emails that look like spam:
 
 

054_Query_DSL/80_Validating_queries.asciidoc

@@ -1,6 +1,6 @@
 === Validating Queries
 
-Queries can become quite complex and, especially when combined with
+Queries can become quite complex and, especially((("validate query API")))((("queries", "validating"))) when combined with
 different analyzers and field mappings, can become a bit difficult to follow.
 The `validate-query` API can be used to check whether a query is valid.
 
@@ -36,7 +36,7 @@ invalid:
 
 ==== Understanding Errors
 
-To find out why it is invalid, add the `explain` parameter to the query
+To find out ((("validate query API", "understqnding errors")))why it is invalid, add the `explain` parameter((("explain parameter"))) to the query
 string:
 
 [source,js]

056_Sorting/95_Fielddata.asciidoc

@@ -4,7 +4,7 @@
 Our final topic in this chapter is about an internal aspect of Elasticsearch.
 While we don't demonstrate any new techniques here, fielddata is an
 important topic that we will refer to repeatedly, and is something that you
-should be aware of.
+should be aware of.((("fielddata")))
 
 When you sort on a field, Elasticsearch needs access to the value of that
 field for every document that matches the query.  The inverted index, which

070_Index_Mgmt/55_Aliases.asciidoc

@@ -7,7 +7,7 @@ to the rescue!
 
 An index _alias_ is like a shortcut or symbolic link, which can point to
 one or more indices, and can be used in any API that expects an index name.
-Aliases((("aliases", "index"))) give us an enormous amount of flexibility. They allow us to do the following:
+Aliases((("aliases, index"))) give us an enormous amount of flexibility. They allow us to do the following:
 
  * Switch transparently between one index and another on a running cluster
  * Group multiple indices (for example, `last_three_months`)

300_Aggregations/105_filtering.asciidoc

@@ -2,7 +2,7 @@
 === Fielddata Filtering
 
 Imagine that you are running a website that allows users to listen to their
-favorite songs.((("fielddata", "filtering")))((("aggregations", "fielddata filtering")))  To make it easier for them to manage their music library,
+favorite songs.((("fielddata", "filtering")))((("aggregations", "fielddata", "filtering")))  To make it easier for them to manage their music library,
 users can tag songs with whatever tags make sense to them.  You will end up
 with a lot of tracks tagged with `rock`, `hiphop`, and `electronica`, but
 also with some tracks tagged with `my_16th_birthday_favorite_anthem`.

300_Aggregations/120_breadth_vs_depth.asciidoc

@@ -51,7 +51,7 @@ This will return a list of the top 10 actors, and for each actor, a list of thei
 top five costars.  This seems like a very modest aggregation; only 50
 values will be returned!
 
-However, this seemingly innocuous query can easily consume a vast amount of
+However, this seemingly ((("aggregations", "fielddata", "datastructure overview")))innocuous query can easily consume a vast amount of
 memory. You can visualize a `terms` aggregation as building a tree in memory.
 The `actors` aggregation will build the first level of the tree, with a bucket
 for every actor.  Then, nested under each node in the first level, the

300_Aggregations/125_Conclusion.asciidoc

@@ -3,7 +3,7 @@
 
 This section covered a lot of ground, and a lot of deeply technical issues.
 Aggregations bring a power and flexibility to Elasticsearch that is hard to 
-overstate.((("aggregations", "power of"))) The ability to nest buckets and metrics, to quickly approximate
+overstate. The ability to nest buckets and metrics, to quickly approximate
 cardinality and percentiles, to find statistical anomalies in your data, all 
 while operating on near-real-time data and in parallel to full-text search--these are game-changers to many organizations.
 

300_Aggregations/20_basic_example.asciidoc

@@ -60,7 +60,7 @@ GET /cars/transactions/_search?search_type=count
 --------------------------------------------------
 // SENSE: 300_Aggregations/20_basic_example.json
 
-<1> Aggregations are placed under the ((("aggs parameter")))top-level `aggs` parameter (the longer `aggregations`
+<1> Aggregations are placed under the ((("aggregations", "aggs parameter")))top-level `aggs` parameter (the longer `aggregations`
 will also work if you prefer that).
 <2> We then name the aggregation whatever we want: `colors`, in this example
 <3> Finally, we define a single bucket of type `terms`.

300_Aggregations/45_filtering.asciidoc

@@ -42,7 +42,7 @@ on those documents.
 [float="true"]
 === Filter Bucket
 
-But what if you would like to filter just the aggregation results?((("filtering", "aggregation results, not the query")))((("aggregations", "filtering")))  Imagine we 
+But what if you would like to filter just the aggregation results?((("filtering", "aggregation results, not the query")))((("aggregations", "filtering just aggregations")))  Imagine we 
 are building the search page for our car dealership.  We want to display
 search results according to what the user searches for.  But we also want
 to enrich the page by including the average price of cars (matching the search)

310_Geopoints/30_Filter_by_geopoint.asciidoc

@@ -25,7 +25,7 @@ geolocation:
 
 All of these filters work in a similar way: the `lat/lon` values are loaded
 into memory for _all documents in the index_, not just the documents that
-match the query (see <<fielddata-intro>>). Each filter performs a slightly
+match the query (see <<fielddata-intro>>).((("aggregations", "fielddata", "filtering"))) Each filter performs a slightly
 different calculation to check whether a point falls into the containing area.
 
 [TIP]