[DOCS] Replace `twitter` dataset in search/agg docs (#60667)

docs/build.gradle

@@ -126,52 +126,6 @@ listSnippets.docs = buildRestTests.docs
 
 listConsoleCandidates.docs = buildRestTests.docs
 
-Closure setupTwitter = { String name, int count ->
-  buildRestTests.setups[name] = '''
-  - do:
-        indices.create:
-          index: twitter
-          body:
-            settings:
-              number_of_shards: 1
-              number_of_replicas: 1
-            mappings:
-              properties:
-                user:
-                  type: keyword
-                  doc_values: true
-                date:
-                  type: date
-                likes:
-                  type: long
-                location:
-                  properties:
-                    city:
-                      type: keyword
-                    country:
-                      type: keyword
-  - do:
-        bulk:
-          index: twitter
-          refresh: true
-          body: |'''
-  for (int i = 0; i < count; i++) {
-    String body
-    if (i == 0) {
-      body = """{"user": "kimchy", "message": "trying out Elasticsearch", "date": "2009-11-15T14:12:12", "likes": 0,
-              "location": { "city": "Amsterdam", "country": "Netherlands" }}"""
-    } else {
-      body = """{"user": "test", "message": "some message with the number $i", "date": "2009-11-15T14:12:12", "likes": $i}"""
-    }
-    buildRestTests.setups[name] += """
-            {"index":{"_id": "$i"}}
-            $body"""
-  }
-}
-setupTwitter('twitter', 5)
-setupTwitter('big_twitter', 120)
-setupTwitter('huge_twitter', 1200)
-
 Closure setupMyIndex = { String name, int count ->
   buildRestTests.setups[name] = '''
   - do:
@@ -185,6 +139,12 @@ Closure setupMyIndex = { String name, int count ->
               properties:
                 "@timestamp":
                   type: date
+                http:
+                  properties:
+                    request:
+                      properties:
+                        method:
+                          type: keyword
                 message:
                   type: text
                 user:
@@ -215,6 +175,31 @@ setupMyIndex('my_index', 5)
 setupMyIndex('my_index_big', 120)
 setupMyIndex('my_index_huge', 1200)
 
+// Used for several full-text search and agg examples
+buildRestTests.setups['messages'] = '''
+  - do:
+        indices.create:
+          index: my-index-000001
+          body:
+            settings:
+              number_of_shards: 1
+              number_of_replicas: 1
+  - do:
+        bulk:
+          index: my-index-000001
+          refresh: true
+          body: |
+            {"index":{"_id": "0"}}
+            {"message": "trying out Elasticsearch" }
+            {"index":{"_id": "1"}}
+            {"message": "some message with the number 1" }
+            {"index":{"_id": "2"}}
+            {"message": "some message with the number 2" }
+            {"index":{"_id": "3"}}
+            {"message": "some message with the number 3" }
+            {"index":{"_id": "4"}}
+            {"message": "some message with the number 4" }'''
+
 buildRestTests.setups['host'] = '''
   # Fetch the http host. We use the host of the master because we know there will always be a master.
   - do:

docs/reference/aggregations/bucket/composite-aggregation.asciidoc

@@ -642,7 +642,7 @@ For instance the following index sort:
 
 [source,console]
 --------------------------------------------------
-PUT twitter
+PUT my-index-000001
 {
   "settings": {
     "index": {

docs/reference/aggregations/metrics/string-stats-aggregation.asciidoc

@@ -19,18 +19,18 @@ The string stats aggregation returns the following results:
 the aggregation. Shannon entropy quantifies the amount of information contained in the field. It is a very useful metric for
 measuring a wide range of properties of a data set, such as diversity, similarity, randomness etc.
 
-Assuming the data consists of a twitter messages:
+For example:
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?size=0
+POST /my-index-000001/_search?size=0
 {
   "aggs": {
     "message_stats": { "string_stats": { "field": "message.keyword" } }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 The above aggregation computes the string statistics for the `message` field in all documents. The aggregation type
 is `string_stats` and the `field` parameter defines the field of the documents the stats will be computed on.
@@ -64,7 +64,7 @@ by the aggregation. To view the probability distribution for all characters, we
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?size=0
+POST /my-index-000001/_search?size=0
 {
   "aggs": {
     "message_stats": {
@@ -76,7 +76,7 @@ POST /twitter/_search?size=0
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 <1> Set the `show_distribution` parameter to `true`, so that probability distribution for all characters is returned in the results.
 
@@ -131,7 +131,7 @@ Computing the message string stats based on a script:
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?size=0
+POST /my-index-000001/_search?size=0
 {
   "aggs": {
     "message_stats": {
@@ -145,14 +145,14 @@ POST /twitter/_search?size=0
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters.
 To use a stored script use the following syntax:
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?size=0
+POST /my-index-000001/_search?size=0
 {
   "aggs": {
     "message_stats": {
@@ -168,7 +168,7 @@ POST /twitter/_search?size=0
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter,stored_example_script]
+// TEST[setup:messages,stored_example_script]
 
 ===== Value Script
 
@@ -176,7 +176,7 @@ We can use a value script to modify the message (eg we can add a prefix) and com
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?size=0
+POST /my-index-000001/_search?size=0
 {
   "aggs": {
     "message_stats": {
@@ -194,7 +194,7 @@ POST /twitter/_search?size=0
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 ==== Missing value
 
@@ -203,7 +203,7 @@ By default they will be ignored but it is also possible to treat them as if they
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?size=0
+POST /my-index-000001/_search?size=0
 {
   "aggs": {
     "message_stats": {
@@ -215,6 +215,6 @@ POST /twitter/_search?size=0
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 <1> Documents without a value in the `message` field will be treated as documents that have the value `[empty message]`.

docs/reference/aggregations/misc.asciidoc

@@ -17,19 +17,19 @@ setting `size=0`. For example:
 
 [source,console,id=returning-only-agg-results-example]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "size": 0,
   "aggregations": {
     "my_agg": {
       "terms": {
-        "field": "text"
+        "field": "user.id"
       }
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 Setting `size` to `0` avoids executing the fetch phase of the search making the request more efficient.
 
@@ -43,7 +43,7 @@ Consider this example where we want to associate the color blue with our `terms`
 
 [source,console,id=agg-metadata-example]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "size": 0,
   "aggs": {
@@ -58,7 +58,7 @@ GET /twitter/_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 Then that piece of metadata will be returned in place for our `titles` terms aggregation
 
@@ -89,24 +89,24 @@ Sometimes you need to know the exact type of an aggregation in order to parse it
  can be used to change the aggregation's name in the response so that it will be prefixed by its internal type.
 
 Considering the following <<search-aggregations-bucket-datehistogram-aggregation,`date_histogram` aggregation>> named
-`tweets_over_time` which has a sub <<search-aggregations-metrics-top-hits-aggregation, 'top_hits` aggregation>> named
+`requests_over_time` which has a sub <<search-aggregations-metrics-top-hits-aggregation, `top_hits` aggregation>> named
  `top_users`:
 
 [source,console,id=returning-aggregation-type-example]
 --------------------------------------------------
-GET /twitter/_search?typed_keys
+GET /my-index-000001/_search?typed_keys
 {
   "aggregations": {
-    "tweets_over_time": {
+    "requests_over_time": {
       "date_histogram": {
-        "field": "date",
+        "field": "@timestamp",
         "calendar_interval": "year"
       },
       "aggregations": {
         "top_users": {
             "top_hits": {
                 "size": 1,
-                "_source": ["user", "likes", "message"]
+                "_source": ["user.id", "http.response.bytes", "message"]
             }
         }
       }
@@ -114,20 +114,20 @@ GET /twitter/_search?typed_keys
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
-In the response, the aggregations names will be changed to respectively `date_histogram#tweets_over_time` and
+In the response, the aggregations names will be changed to respectively `date_histogram#requests_over_time` and
 `top_hits#top_users`, reflecting the internal types of each aggregation:
 
 [source,console-result]
 --------------------------------------------------
 {
   "aggregations": {
-    "date_histogram#tweets_over_time": {                    <1>
+    "date_histogram#requests_over_time": {                    <1>
       "buckets": [
         {
-          "key_as_string": "2009-01-01T00:00:00.000Z",
-          "key": 1230768000000,
+          "key_as_string": "2099-01-01T00:00:00.000Z",
+          "key": 4070908800000,
           "doc_count": 5,
           "top_hits#top_users": {                           <2>
             "hits": {
@@ -138,13 +138,13 @@ In the response, the aggregations names will be changed to respectively `date_hi
               "max_score": 1.0,
               "hits": [
                 {
-                  "_index": "twitter",
+                  "_index": "my-index-000001",
                   "_id": "0",
                   "_score": 1.0,
                   "_source": {
-                    "user": "kimchy",
-                    "message": "trying out Elasticsearch",
-                    "likes": 0
+                    "user": { "id": "kimchy"},
+                    "message": "GET /search HTTP/1.1 200 1070000",
+                    "http": { "response": { "bytes": 1070000 } }
                   }
                 }
               ]
@@ -159,7 +159,7 @@ In the response, the aggregations names will be changed to respectively `date_hi
 --------------------------------------------------
 // TESTRESPONSE[s/\.\.\./"took": "$body.took", "timed_out": false, "_shards": "$body._shards", "hits": "$body.hits"/]
 
-<1> The name `tweets_over_time` now contains the `date_histogram` prefix.
+<1> The name `requests_over_time` now contains the `date_histogram` prefix.
 <2> The name `top_users` now contains the `top_hits` prefix.
 
 NOTE: For some aggregations, it is possible that the returned type is not the same as the one provided with the

docs/reference/indices/put-mapping.asciidoc

@@ -11,7 +11,7 @@ For data streams, these changes are applied to all backing indices by default.
 
 [source,console]
 ----
-PUT /twitter/_mapping
+PUT /my-index-000001/_mapping
 {
   "properties": {
     "email": {
@@ -20,7 +20,7 @@ PUT /twitter/_mapping
   }
 }
 ----
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [[put-mapping-api-request]]
 ==== {api-request-title}
@@ -114,42 +114,38 @@ PUT /publications/_mapping
 ===== Multiple targets
 
 The PUT mapping API can be applied to multiple data streams or indices with a single request.
-For example, you can update mappings for the `twitter-1` and `twitter-2` indices at the same time:
+For example, you can update mappings for the `my-index-000001` and `my-index-000002` indices at the same time:
 
 [source,console]
 --------------------------------------------------
 # Create the two indices
-PUT /twitter-1
-PUT /twitter-2
+PUT /my-index-000001
+PUT /my-index-000002
 
 # Update both mappings
-PUT /twitter-1,twitter-2/_mapping <1>
+PUT /my-index-000001,my-index-000002/_mapping
 {
   "properties": {
-    "user_name": {
-      "type": "text"
+    "user": {
+      "properties": {
+        "name": {
+          "type": "keyword"
+        }
+      }
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
-
-<1> Note that the indices specified (`twitter-1,twitter-2`) follows <<multi-index,multiple index names>> and wildcard format.
 
 
 [[add-new-field-to-object]]
 ===== Add new properties to an existing object field
 
-You can use the put mapping API
-to add new properties
-to an existing <<object,`object`>> field.
-To see how this works,
-try the following example.
+You can use the put mapping API to add new properties to an existing
+<<object,`object`>> field. To see how this works, try the following example.
 
-Use the <<indices-create-index,create index>> API
-to create an index
-with the `name` object field
-and an inner `first` text field.
+Use the <<indices-create-index,create index>> API to create an index with the
+`name` object field and an inner `first` text field.
 
 [source,console]
 ----
@@ -169,9 +165,8 @@ PUT /my-index-000001
 }
 ----
 
-Use the put mapping API
-to add a new inner `last` text field
-to the `name` field.
+Use the put mapping API to add a new inner `last` text field to the `name`
+field.
 
 [source,console]
 ----
@@ -190,56 +185,18 @@ PUT /my-index-000001/_mapping
 ----
 // TEST[continued]
 
-Use the <<indices-get-mapping,get mapping>> API
-to verify your changes.
-
-[source,console]
-----
-GET /my-index-000001/_mapping
-----
-// TEST[continued]
-
-The API returns the following response:
-
-[source,console-result]
-----
-{
-  "my-index-000001" : {
-    "mappings" : {
-      "properties" : {
-        "name" : {
-          "properties" : {
-            "first" : {
-              "type" : "text"
-            },
-            "last" : {
-              "type" : "text"
-            }
-          }
-        }
-      }
-    }
-  }
-}
-----
-
 
 [[add-multi-fields-existing-field-ex]]
 ===== Add multi-fields to an existing field
 
-<<multi-fields,Multi-fields>>
-let you index the same field
-in different ways.
-You can use the put mapping API
-to update the `fields` mapping parameter
-and enable multi-fields for an existing field.
+<<multi-fields,Multi-fields>> let you index the same field in different ways.
+You can use the put mapping API to update the `fields` mapping parameter and
+enable multi-fields for an existing field.
 
-To see how this works,
-try the following example.
+To see how this works, try the following example.
 
-Use the <<indices-create-index,create index>> API
-to create an index
-with the `city` <<text,text>> field.
+Use the <<indices-create-index,create index>> API to create an index with the
+`city` <<text,text>> field.
 
 [source,console]
 ----
@@ -255,14 +212,11 @@ PUT /my-index-000001
 }
 ----
 
-While text fields work well for full-text search,
-<<keyword,keyword>> fields are not analyzed
-and may work better for sorting or aggregations.
+While text fields work well for full-text search, <<keyword,keyword>> fields are
+not analyzed and may work better for sorting or aggregations.
 
-Use the put mapping API
-to enable a multi-field for the `city` field.
-This request adds the `city.raw` keyword multi-field,
-which can be used for sorting.
+Use the put mapping API to enable a multi-field for the `city` field. This
+request adds the `city.raw` keyword multi-field, which can be used for sorting.
 
 [source,console]
 ----
@@ -282,57 +236,20 @@ PUT /my-index-000001/_mapping
 ----
 // TEST[continued]
 
-Use the <<indices-get-mapping,get mapping>> API
-to verify your changes.
-
-[source,console]
-----
-GET /my-index-000001/_mapping
-----
-// TEST[continued]
-
-The API returns the following response:
-
-[source,console-result]
-----
-{
-  "my-index-000001" : {
-    "mappings" : {
-      "properties" : {
-        "city" : {
-          "type" : "text",
-          "fields" : {
-            "raw" : {
-              "type" : "keyword"
-            }
-          }
-        }
-      }
-    }
-  }
-}
-----
-
 
 [[change-existing-mapping-parms]]
 ===== Change supported mapping parameters for an existing field
 
-The documentation for each <<mapping-params,mapping parameter>>
-indicates whether you can update it
-for an existing field
-using the put mapping API.
-For example,
-you can use the put mapping API
-to update the <<ignore-above,`ignore_above`>> parameter.
+The documentation for each <<mapping-params,mapping parameter>> indicates
+whether you can update it for an existing field using the put mapping API. For
+example, you can use the put mapping API to update the
+<<ignore-above,`ignore_above`>> parameter.
 
-To see how this works,
-try the following example.
+To see how this works, try the following example.
 
-Use the <<indices-create-index,create index>> API to create an index
-containing a `user_id` keyword field.
-The `user_id` field
-has an `ignore_above` parameter value
-of `20`.
+Use the <<indices-create-index,create index>> API to create an index containing
+a `user_id` keyword field. The `user_id` field has an `ignore_above` parameter
+value of `20`.
 
 [source,console]
 ----
@@ -349,9 +266,7 @@ PUT /my-index-000001
 }
 ----
 
-Use the put mapping API
-to change the `ignore_above` parameter value
-to `100`.
+Use the put mapping API to change the `ignore_above` parameter value to `100`.
 
 [source,console]
 ----
@@ -367,33 +282,6 @@ PUT /my-index-000001/_mapping
 ----
 // TEST[continued]
 
-Use the <<indices-get-mapping,get mapping>> API
-to verify your changes.
-
-[source,console]
-----
-GET /my-index-000001/_mapping
-----
-// TEST[continued]
-
-The API returns the following response:
-
-[source,console-result]
-----
-{
-  "my-index-000001" : {
-    "mappings" : {
-      "properties" : {
-        "user_id" : {
-          "type" : "keyword",
-          "ignore_above" : 100
-        }
-      }
-    }
-  }
-}
-----
-
 
 [[updating-field-mappings]]
 ===== Change the mapping of an existing field
@@ -415,13 +303,13 @@ To see how you can change the mapping of an existing field in an index,
 try the following example.
 
 Use the <<indices-create-index,create index>> API
-to create the `users` index
+to create an index
 with the `user_id` field
 with the <<number,`long`>> field type.
 
 [source,console]
 ----
-PUT /users
+PUT /my-index-000001
 {
   "mappings" : {
     "properties": {
@@ -439,12 +327,12 @@ with `user_id` field values.
 
 [source,console]
 ----
-POST /users/_doc?refresh=wait_for
+POST /my-index-000001/_doc?refresh=wait_for
 {
   "user_id" : 12345
 }
 
-POST /users/_doc?refresh=wait_for
+POST /my-index-000001/_doc?refresh=wait_for
 {
   "user_id" : 12346
 }
@@ -454,11 +342,11 @@ POST /users/_doc?refresh=wait_for
 To change the `user_id` field
 to the <<keyword,`keyword`>> field type,
 use the create index API
-to create the `new_users` index with the correct mapping.
+to create a new index with the correct mapping.
 
 [source,console]
 ----
-PUT /new_users
+PUT /my-new-index-000001
 {
   "mappings" : {
     "properties": {
@@ -472,49 +360,23 @@ PUT /new_users
 // TEST[continued]
 
 Use the <<docs-reindex,reindex>> API
-to copy documents from the `users` index
-to the `new_users` index.
+to copy documents from the old index
+to the new one.
 
 [source,console]
 ----
 POST /_reindex
 {
   "source": {
-    "index": "users"
+    "index": "my-index-000001"
   },
   "dest": {
-    "index": "new_users"
+    "index": "my-new-index-000001"
   }
 }
 ----
 // TEST[continued]
 
-The API returns the following response:
-
-[source,console-result]
-----
-{
-  "took": 147,
-  "timed_out": false,
-  "total": 2,
-  "updated": 0,
-  "created": 2,
-  "deleted": 0,
-  "batches": 1,
-  "version_conflicts": 0,
-  "noops": 0,
-  "retries": {
-    "bulk": 0,
-    "search": 0
-  },
-  "throttled_millis": 0,
-  "requests_per_second": -1.0,
-  "throttled_until_millis": 0,
-  "failures" : [ ]
-}
-----
-// TESTRESPONSE[s/"took": 147/"took": "$body.took"/]
-
 
 [[rename-existing-field]]
 ===== Rename a field
@@ -559,33 +421,3 @@ PUT /my-index-000001/_mapping
 }
 ----
 // TEST[continued]
-
-Use the <<indices-get-mapping,get mapping>> API
-to verify your changes.
-
-[source,console]
-----
-GET /my-index-000001/_mapping
-----
-// TEST[continued]
-
-The API returns the following response:
-
-[source,console-result]
-----
-{
-  "my-index-000001" : {
-    "mappings" : {
-      "properties" : {
-        "user_id" : {
-          "type" : "alias",
-          "path" : "user_identifier"
-        },
-        "user_identifier" : {
-          "type" : "keyword"
-        }
-      }
-    }
-  }
-}
-----

docs/reference/query-dsl/function-score-query.asciidoc

@@ -144,7 +144,7 @@ GET /_search
       },
       "script_score": {
         "script": {
-          "source": "Math.log(2 + doc['likes'].value)"
+          "source": "Math.log(2 + doc['my-int'].value)"
         }
       }
     }
@@ -186,7 +186,7 @@ GET /_search
             "a": 5,
             "b": 1.2
           },
-          "source": "params.a / Math.pow(params.b, doc['likes'].value)"
+          "source": "params.a / Math.pow(params.b, doc['my-int'].value)"
         }
       }
     }
@@ -261,7 +261,7 @@ influence the score. It's similar to using the `script_score` function, however,
 it avoids the overhead of scripting. If used on a multi-valued field, only the
 first value of the field is used in calculations.
 
-As an example, imagine you have a document indexed with a numeric `likes`
+As an example, imagine you have a document indexed with a numeric `my-int`
 field and wish to influence the score of a document with this field, an example
 doing so would look like:
 
@@ -272,7 +272,7 @@ GET /_search
   "query": {
     "function_score": {
       "field_value_factor": {
-        "field": "likes",
+        "field": "my-int",
         "factor": 1.2,
         "modifier": "sqrt",
         "missing": 1
@@ -285,7 +285,7 @@ GET /_search
 
 Which will translate into the following formula for scoring:
 
-`sqrt(1.2 * doc['likes'].value)`
+`sqrt(1.2 * doc['my-int'].value)`
 
 There are a number of options for the `field_value_factor` function:
 

docs/reference/query-dsl/script-score-query.asciidoc

@@ -12,7 +12,7 @@ The `script_score` query is useful if, for example, a scoring function is expens
 
 [[script-score-query-ex-request]]
 ==== Example request
-The following `script_score` query assigns each returned document a score equal to the `likes` field value divided by `10`.
+The following `script_score` query assigns each returned document a score equal to the `my-int` field value divided by `10`.
 
 [source,console]
 --------------------------------------------------
@@ -24,7 +24,7 @@ GET /_search
         "match": { "message": "elasticsearch" }
       },
       "script": {
-        "source": "doc['likes'].value / 10 "
+        "source": "doc['my-int'].value / 10 "
       }
     }
   }
@@ -90,7 +90,7 @@ These functions take advantage of efficiencies from {es}' internal mechanisms.
 [source,js]
 --------------------------------------------------
 "script" : {
-    "source" : "saturation(doc['likes'].value, 1)"
+    "source" : "saturation(doc['my-int'].value, 1)"
 }
 --------------------------------------------------
 // NOTCONSOLE
@@ -102,7 +102,7 @@ These functions take advantage of efficiencies from {es}' internal mechanisms.
 [source,js]
 --------------------------------------------------
 "script" : {
-    "source" : "sigmoid(doc['likes'].value, 2, 1)"
+    "source" : "sigmoid(doc['my-int'].value, 2, 1)"
 }
 --------------------------------------------------
 // NOTCONSOLE
@@ -343,7 +343,7 @@ Using an <<search-explain, explain request>> provides an explanation of how the
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_explain/0
+GET /my-index-000001/_explain/0
 {
   "query": {
     "script_score": {
@@ -352,18 +352,18 @@ GET /twitter/_explain/0
       },
       "script": {
         "source": """
-          long likes = doc['likes'].value;
-          double normalizedLikes = likes / 10;
+          long count = doc['count'].value;
+          double normalizedCount = count / 10;
           if (explanation != null) {
-            explanation.set('normalized likes = likes / 10 = ' + likes + ' / 10 = ' + normalizedLikes);
+            explanation.set('normalized count = count / 10 = ' + count + ' / 10 = ' + normalizedCount);
           }
-          return normalizedLikes;
+          return normalizedCount;
         """
       }
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 Note that the `explanation` will be null when using in a normal `_search` request, so having a conditional guard is best practice.

docs/reference/scripting/using.asciidoc

@@ -116,7 +116,7 @@ Short form:
 
 [source,js]
 ----------------------
-  "script": "ctx._source.likes++"
+  "script": "ctx._source.my-int++"
 ----------------------
 // NOTCONSOLE
 
@@ -125,7 +125,7 @@ The same script in the normal form:
 [source,js]
 ----------------------
   "script": {
-    "source": "ctx._source.likes++"
+    "source": "ctx._source.my-int++"
   }
 ----------------------
 // NOTCONSOLE

docs/reference/search/clear-scroll-api.asciidoc

@@ -18,7 +18,7 @@ GET /_search?scroll=1m
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 ////
 
 [source,console]

docs/reference/search/count.asciidoc

@@ -5,12 +5,12 @@ Gets the number of matches for a search query.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_count?q=user:kimchy
+GET /my-index-000001/_count?q=user:kimchy
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 NOTE: The query being sent in the body must be nested in a `query` key, same as
-the <<search-search,search api>> works.
+the <<search-search,search API>> works.
 
 
 [[search-count-api-request]]
@@ -97,23 +97,23 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=query]
 
 [source,console]
 --------------------------------------------------
-PUT /twitter/_doc/1?refresh
+PUT /my-index-000001/_doc/1?refresh
 {
-  "user": "kimchy"
+  "user.id": "kimchy"
 }
 
-GET /twitter/_count?q=user:kimchy
+GET /my-index-000001/_count?q=user:kimchy
 
-GET /twitter/_count
+GET /my-index-000001/_count
 {
   "query" : {
-    "term" : { "user" : "kimchy" }
+    "term" : { "user.id" : "kimchy" }
   }
 }
 --------------------------------------------------
 
-Both examples above do the same: count the number of tweets from the `twitter` 
-index for a certain user. The API returns the following response:
+Both examples above do the same: count the number of documents in
+`my-index-000001` with a `user.id` of `kimchy`. The API returns the following response:
 
 [source,console-result]
 --------------------------------------------------

docs/reference/search/explain.asciidoc

@@ -6,14 +6,14 @@ query.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_explain/0
+GET /my-index-000001/_explain/0
 {
   "query" : {
     "match" : { "message" : "elasticsearch" }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 
 [[sample-api-request]]
@@ -87,14 +87,14 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=query]
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_explain/0
+GET /my-index-000001/_explain/0
 {
   "query" : {
     "match" : { "message" : "elasticsearch" }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 
 The API returns the following response:
@@ -102,7 +102,7 @@ The API returns the following response:
 [source,console-result]
 --------------------------------------------------
 {
-   "_index":"twitter",
+   "_index":"my-index-000001",
    "_id":"0",
    "matched":true,
    "explanation":{
@@ -180,9 +180,9 @@ explain API:
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_explain/0?q=message:search
+GET /my-index-000001/_explain/0?q=message:search
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 
 The API returns the same result as the previous request.

docs/reference/search/field-caps.asciidoc

@@ -116,9 +116,9 @@ The request can be restricted to specific data streams and indices:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_field_caps?fields=rating
+GET my-index-000001/_field_caps?fields=rating
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 The next example API call requests information about the `rating` and the
@@ -228,7 +228,7 @@ It is also possible to filter indices with a query:
 
 [source,console]
 --------------------------------------------------
-POST twitter*/_field_caps?fields=rating
+POST my-index-*/_field_caps?fields=rating
 {
   "index_filter": {
     "range": {
@@ -239,7 +239,7 @@ POST twitter*/_field_caps?fields=rating
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 In which case indices that rewrite the provided filter to `match_none` on every shard

docs/reference/search/multi-search.asciidoc

@@ -8,13 +8,13 @@ Executes several searches with a single API request.
 
 [source,console]
 --------------------------------------------------
-GET twitter/_msearch
+GET my-index-000001/_msearch
 { }
 {"query" : {"match" : { "message": "this is a test"}}}
-{"index": "twitter2"}
+{"index": "my-index-000002"}
 {"query" : {"match_all" : {}}}
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [[search-multi-search-api-request]]
 ==== {api-request-title}
@@ -299,19 +299,19 @@ unless explicitly specified in the header's `index` parameter. For example:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_msearch
+GET my-index-000001/_msearch
 {}
 {"query" : {"match_all" : {}}, "from" : 0, "size" : 10}
 {}
 {"query" : {"match_all" : {}}}
-{"index" : "twitter2"}
+{"index" : "my-index-000002"}
 {"query" : {"match_all" : {}}}
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
-The above will execute the search against the `twitter` index for all the
+The above will execute the search against the `my-index-000001` index for all the
 requests that don't define an `index` target in the request body. The last
-search will be executed against the `twitter2` index.
+search will be executed against the `my-index-000002` index.
 
 The `search_type` can be set in a similar manner to globally apply to
 all search requests.
@@ -333,12 +333,12 @@ templates:
 [source,console]
 -----------------------------------------------
 GET _msearch/template
-{"index" : "twitter"}
+{"index" : "my-index-000001"}
 { "source" : "{ \"query\": { \"match\": { \"message\" : \"{{keywords}}\" } } } }", "params": { "query_type": "match", "keywords": "some message" } }
-{"index" : "twitter"}
+{"index" : "my-index-000001"}
 { "source" : "{ \"query\": { \"match_{{template}}\": {} } }", "params": { "template": "all" } }
 -----------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 You can also create search templates:
@@ -359,7 +359,7 @@ POST /_scripts/my_template_1
   }
 }
 ------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 [source,console]

docs/reference/search/profile.asciidoc

@@ -30,15 +30,15 @@ Any `_search` request can be profiled by adding a top-level `profile` parameter:
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "profile": true,<1>
   "query" : {
-    "match" : { "message" : "some number" }
+    "match" : { "message" : "GET /search" }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 <1> Setting the top-level `profile` parameter to `true` will enable profiling
 for the search.
@@ -49,127 +49,127 @@ The API returns the following result:
 [source,console-result]
 --------------------------------------------------
 {
-   "took": 25,
-   "timed_out": false,
-   "_shards": {
-      "total": 1,
-      "successful": 1,
-      "skipped" : 0,
-      "failed": 0
-   },
-   "hits": {
-      "total" : {
-          "value": 4,
-          "relation": "eq"
-      },
-      "max_score": 0.5093388,
-      "hits": [...] <1>
-   },
-   "profile": {
-     "shards": [
-        {
-           "id": "[2aE02wS1R8q_QFnYu6vDVQ][twitter][0]",
-           "searches": [
+  "took": 25,
+  "timed_out": false,
+  "_shards": {
+    "total": 1,
+    "successful": 1,
+    "skipped": 0,
+    "failed": 0
+  },
+  "hits": {
+    "total": {
+      "value": 5,
+      "relation": "eq"
+    },
+    "max_score": 0.17402273,
+    "hits": [...] <1>
+  },
+  "profile": {
+    "shards": [
+      {
+        "id": "[2aE02wS1R8q_QFnYu6vDVQ][my-index-000001][0]",
+        "searches": [
+          {
+            "query": [
               {
-                 "query": [
-                    {
-                       "type": "BooleanQuery",
-                       "description": "message:some message:number",
-                       "time_in_nanos": "1873811",
-                       "breakdown": {
-                          "score": 51306,
-                          "score_count": 4,
-                          "build_scorer": 2935582,
-                          "build_scorer_count": 1,
-                          "match": 0,
-                          "match_count": 0,
-                          "create_weight": 919297,
-                          "create_weight_count": 1,
-                          "next_doc": 53876,
-                          "next_doc_count": 5,
-                          "advance": 0,
-                          "advance_count": 0,
-                          "compute_max_score": 0,
-                          "compute_max_score_count": 0,
-                          "shallow_advance": 0,
-                          "shallow_advance_count": 0,
-                          "set_min_competitive_score": 0,
-                          "set_min_competitive_score_count": 0
-                       },
-                       "children": [
-                          {
-                             "type": "TermQuery",
-                             "description": "message:some",
-                             "time_in_nanos": "391943",
-                             "breakdown": {
-                                "score": 28776,
-                                "score_count": 4,
-                                "build_scorer": 784451,
-                                "build_scorer_count": 1,
-                                "match": 0,
-                                "match_count": 0,
-                                "create_weight": 1669564,
-                                "create_weight_count": 1,
-                                "next_doc": 10111,
-                                "next_doc_count": 5,
-                                "advance": 0,
-                                "advance_count": 0,
-                                "compute_max_score": 0,
-                                "compute_max_score_count": 0,
-                                "shallow_advance": 0,
-                                "shallow_advance_count": 0,
-                                "set_min_competitive_score": 0,
-                                "set_min_competitive_score_count": 0
-                             }
-                          },
-                          {
-                             "type": "TermQuery",
-                             "description": "message:number",
-                             "time_in_nanos": "210682",
-                             "breakdown": {
-                                "score": 4552,
-                                "score_count": 4,
-                                "build_scorer": 42602,
-                                "build_scorer_count": 1,
-                                "match": 0,
-                                "match_count": 0,
-                                "create_weight": 89323,
-                                "create_weight_count": 1,
-                                "next_doc": 2852,
-                                "next_doc_count": 5,
-                                "advance": 0,
-                                "advance_count": 0,
-                                "compute_max_score": 0,
-                                "compute_max_score_count": 0,
-                                "shallow_advance": 0,
-                                "shallow_advance_count": 0,
-                                "set_min_competitive_score": 0,
-                                "set_min_competitive_score_count": 0
-                             }
-                          }
-                       ]
+                "type": "BooleanQuery",
+                "description": "message:get
+                message:search", "time_in_nanos" : 11972972, "breakdown" :
+                {
+                  "set_min_competitive_score_count": 0,
+                  "match_count": 5,
+                  "shallow_advance_count": 0,
+                  "set_min_competitive_score": 0,
+                  "next_doc": 39022,
+                  "match": 4456,
+                  "next_doc_count": 5,
+                  "score_count": 5,
+                  "compute_max_score_count": 0,
+                  "compute_max_score": 0,
+                  "advance": 84525,
+                  "advance_count": 1,
+                  "score": 37779,
+                  "build_scorer_count": 2,
+                  "create_weight": 4694895,
+                  "shallow_advance": 0,
+                  "create_weight_count": 1,
+                  "build_scorer": 7112295
+                },
+                "children": [
+                  {
+                    "type": "TermQuery",
+                    "description": "message:get",
+                    "time_in_nanos": 3801935,
+                    "breakdown": {
+                      "set_min_competitive_score_count": 0,
+                      "match_count": 0,
+                      "shallow_advance_count": 3,
+                      "set_min_competitive_score": 0,
+                      "next_doc": 0,
+                      "match": 0,
+                      "next_doc_count": 0,
+                      "score_count": 5,
+                      "compute_max_score_count": 3,
+                      "compute_max_score": 32487,
+                      "advance": 5749,
+                      "advance_count": 6,
+                      "score": 16219,
+                      "build_scorer_count": 3,
+                      "create_weight": 2382719,
+                      "shallow_advance": 9754,
+                      "create_weight_count": 1,
+                      "build_scorer": 1355007
                     }
-                 ],
-                 "rewrite_time": 51443,
-                 "collector": [
-                    {
-                       "name": "SimpleTopScoreDocCollector",
-                       "reason": "search_top_hits",
-                       "time_in_nanos": "32273"
+                  },
+                  {
+                    "type": "TermQuery",
+                    "description": "message:search",
+                    "time_in_nanos": 205654,
+                    "breakdown": {
+                      "set_min_competitive_score_count": 0,
+                      "match_count": 0,
+                      "shallow_advance_count": 3,
+                      "set_min_competitive_score": 0,
+                      "next_doc": 0,
+                      "match": 0,
+                      "next_doc_count": 0,
+                      "score_count": 5,
+                      "compute_max_score_count": 3,
+                      "compute_max_score": 6678,
+                      "advance": 12733,
+                      "advance_count": 6,
+                      "score": 6627,
+                      "build_scorer_count": 3,
+                      "create_weight": 130951,
+                      "shallow_advance": 2512,
+                      "create_weight_count": 1,
+                      "build_scorer": 46153
                     }
-                 ]
+                  }
+                ]
               }
-           ],
-           "aggregations": []
-        }
-     ]
-   }
+            ],
+            "rewrite_time": 451233,
+            "collector": [
+              {
+                "name": "SimpleTopScoreDocCollector",
+                "reason": "search_top_hits",
+                "time_in_nanos": 775274
+              }
+            ]
+          }
+        ],
+        "aggregations": []
+      }
+    ]
+  }
 }
 --------------------------------------------------
 // TESTRESPONSE[s/"took": 25/"took": $body.took/]
 // TESTRESPONSE[s/"hits": \[...\]/"hits": $body.$_path/]
 // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
-// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[twitter\]\[0\]/$body.$_path/]
+// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[my-index-000001\]\[0\]/$body.$_path/]
 
 <1> Search results are returned, but were omitted here for brevity.
 
@@ -185,7 +185,7 @@ The overall structure of the profile response is as follows:
    "profile": {
         "shards": [
            {
-              "id": "[2aE02wS1R8q_QFnYu6vDVQ][twitter][0]",  <1>
+              "id": "[2aE02wS1R8q_QFnYu6vDVQ][my-index-000001][0]",  <1>
               "searches": [
                  {
                     "query": [...],             <2>
@@ -201,7 +201,7 @@ The overall structure of the profile response is as follows:
 --------------------------------------------------
 // TESTRESPONSE[s/"profile": /"took": $body.took, "timed_out": $body.timed_out, "_shards": $body._shards, "hits": $body.hits, "profile": /]
 // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
-// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[twitter\]\[0\]/$body.$_path/]
+// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[my-index-000001\]\[0\]/$body.$_path/]
 // TESTRESPONSE[s/"query": \[...\]/"query": $body.$_path/]
 // TESTRESPONSE[s/"collector": \[...\]/"collector": $body.$_path/]
 // TESTRESPONSE[s/"aggregations": \[...\]/"aggregations": []/]
@@ -271,20 +271,20 @@ Using our previous `match` query example, let's analyze the `query` section:
 "query": [
     {
        "type": "BooleanQuery",
-       "description": "message:some message:number",
-       "time_in_nanos": "1873811",
+       "description": "message:get message:search",
+       "time_in_nanos": "11972972",
        "breakdown": {...},               <1>
        "children": [
           {
              "type": "TermQuery",
-             "description": "message:some",
-             "time_in_nanos": "391943",
+             "description": "message:get",
+             "time_in_nanos": "3801935",
              "breakdown": {...}
           },
           {
              "type": "TermQuery",
-             "description": "message:number",
-             "time_in_nanos": "210682",
+             "description": "message:search",
+             "time_in_nanos": "205654",
              "breakdown": {...}
           }
        ]
@@ -323,27 +323,27 @@ Lucene execution:
 [source,console-result]
 --------------------------------------------------
 "breakdown": {
-   "score": 51306,
-   "score_count": 4,
-   "build_scorer": 2935582,
-   "build_scorer_count": 1,
-   "match": 0,
-   "match_count": 0,
-   "create_weight": 919297,
-   "create_weight_count": 1,
-   "next_doc": 53876,
-   "next_doc_count": 5,
-   "advance": 0,
-   "advance_count": 0,
-   "compute_max_score": 0,
-   "compute_max_score_count": 0,
-   "shallow_advance": 0,
-   "shallow_advance_count": 0,
-   "set_min_competitive_score": 0,
-   "set_min_competitive_score_count": 0
+  "set_min_competitive_score_count": 0,
+  "match_count": 5,
+  "shallow_advance_count": 0,
+  "set_min_competitive_score": 0,
+  "next_doc": 39022,
+  "match": 4456,
+  "next_doc_count": 5,
+  "score_count": 5,
+  "compute_max_score_count": 0,
+  "compute_max_score": 0,
+  "advance": 84525,
+  "advance_count": 1,
+  "score": 37779,
+  "build_scorer_count": 2,
+  "create_weight": 4694895,
+  "shallow_advance": 0,
+  "create_weight_count": 1,
+  "build_scorer": 7112295
 }
 --------------------------------------------------
-// TESTRESPONSE[s/^/{\n"took": $body.took,\n"timed_out": $body.timed_out,\n"_shards": $body._shards,\n"hits": $body.hits,\n"profile": {\n"shards": [ {\n"id": "$body.$_path",\n"searches": [{\n"query": [{\n"type": "BooleanQuery",\n"description": "message:some message:number",\n"time_in_nanos": $body.$_path,/]
+// TESTRESPONSE[s/^/{\n"took": $body.took,\n"timed_out": $body.timed_out,\n"_shards": $body._shards,\n"hits": $body.hits,\n"profile": {\n"shards": [ {\n"id": "$body.$_path",\n"searches": [{\n"query": [{\n"type": "BooleanQuery",\n"description": "message:get message:search",\n"time_in_nanos": $body.$_path,/]
 // TESTRESPONSE[s/}$/},\n"children": $body.$_path}],\n"rewrite_time": $body.$_path, "collector": $body.$_path}], "aggregations": []}]}}/]
 // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
 
@@ -437,11 +437,11 @@ Looking at the previous example:
 [source,console-result]
 --------------------------------------------------
 "collector": [
-   {
-      "name": "SimpleTopScoreDocCollector",
-      "reason": "search_top_hits",
-      "time_in_nanos": "32273"
-   }
+  {
+    "name": "SimpleTopScoreDocCollector",
+    "reason": "search_top_hits",
+    "time_in_nanos": 775274
+  }
 ]
 --------------------------------------------------
 // TESTRESPONSE[s/^/{\n"took": $body.took,\n"timed_out": $body.timed_out,\n"_shards": $body._shards,\n"hits": $body.hits,\n"profile": {\n"shards": [ {\n"id": "$body.$_path",\n"searches": [{\n"query": $body.$_path,\n"rewrite_time": $body.$_path,/]
@@ -531,20 +531,20 @@ profile the following query:
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "profile": true,
   "query": {
     "term": {
-      "user": {
-        "value": "test"
+      "user.id": {
+        "value": "elkbee"
       }
     }
   },
   "aggs": {
     "my_scoped_agg": {
       "terms": {
-        "field": "likes"
+        "field": "http.response.status_code"
       }
     },
     "my_global_agg": {
@@ -552,7 +552,7 @@ GET /twitter/_search
       "aggs": {
         "my_level_agg": {
           "terms": {
-            "field": "likes"
+            "field": "http.response.status_code"
           }
         }
       }
@@ -560,13 +560,14 @@ GET /twitter/_search
   },
   "post_filter": {
     "match": {
-      "message": "some"
+      "message": "search"
     }
   }
 }
 --------------------------------------------------
+// TEST[setup:my_index]
 // TEST[s/_search/_search\?filter_path=profile.shards.id,profile.shards.searches,profile.shards.aggregations/]
-// TEST[continued]
+
 
 This example has:
 
@@ -581,112 +582,112 @@ The API returns the following result:
 [source,console-result]
 --------------------------------------------------
 {
-   ...
-   "profile": {
-         "shards": [
-            {
-               "id": "[P6-vulHtQRWuD4YnubWb7A][test][0]",
-               "searches": [
+  ...
+  "profile": {
+    "shards": [
+      {
+        "id": "[P6-vulHtQRWuD4YnubWb7A][my-index-000001][0]",
+        "searches": [
+          {
+            "query": [
+              {
+                "type": "TermQuery",
+                "description": "message:search",
+                "time_in_nanos": 141618,
+                "breakdown": {
+                  "set_min_competitive_score_count": 0,
+                  "match_count": 0,
+                  "shallow_advance_count": 0,
+                  "set_min_competitive_score": 0,
+                  "next_doc": 0,
+                  "match": 0,
+                  "next_doc_count": 0,
+                  "score_count": 0,
+                  "compute_max_score_count": 0,
+                  "compute_max_score": 0,
+                  "advance": 3942,
+                  "advance_count": 4,
+                  "score": 0,
+                  "build_scorer_count": 2,
+                  "create_weight": 38380,
+                  "shallow_advance": 0,
+                  "create_weight_count": 1,
+                  "build_scorer": 99296
+                }
+              },
+              {
+                "type": "TermQuery",
+                "description": "user.id:elkbee",
+                "time_in_nanos": 163081,
+                "breakdown": {
+                  "set_min_competitive_score_count": 0,
+                  "match_count": 0,
+                  "shallow_advance_count": 0,
+                  "set_min_competitive_score": 0,
+                  "next_doc": 2447,
+                  "match": 0,
+                  "next_doc_count": 4,
+                  "score_count": 4,
+                  "compute_max_score_count": 0,
+                  "compute_max_score": 0,
+                  "advance": 3552,
+                  "advance_count": 1,
+                  "score": 5027,
+                  "build_scorer_count": 2,
+                  "create_weight": 107840,
+                  "shallow_advance": 0,
+                  "create_weight_count": 1,
+                  "build_scorer": 44215
+                }
+              }
+            ],
+            "rewrite_time": 4769,
+            "collector": [
+              {
+                "name": "MultiCollector",
+                "reason": "search_multi",
+                "time_in_nanos": 1945072,
+                "children": [
+                  {
+                    "name": "FilteredCollector",
+                    "reason": "search_post_filter",
+                    "time_in_nanos": 500850,
+                    "children": [
+                      {
+                        "name": "SimpleTopScoreDocCollector",
+                        "reason": "search_top_hits",
+                        "time_in_nanos": 22577
+                      }
+                    ]
+                  },
                   {
-                     "query": [
-                        {
-                           "type": "TermQuery",
-                           "description": "message:some",
-                           "time_in_nanos": "409456",
-                           "breakdown": {
-                              "score": 0,
-                              "build_scorer_count": 1,
-                              "match_count": 0,
-                              "create_weight": 31584,
-                              "next_doc": 0,
-                              "match": 0,
-                              "create_weight_count": 1,
-                              "next_doc_count": 2,
-                              "score_count": 1,
-                              "build_scorer": 377872,
-                              "advance": 0,
-                              "advance_count": 0,
-                              "compute_max_score": 0,
-                              "compute_max_score_count": 0,
-                              "shallow_advance": 0,
-                              "shallow_advance_count": 0,
-                              "set_min_competitive_score": 0,
-                              "set_min_competitive_score_count": 0
-                           }
-                        },
-                        {
-                           "type": "TermQuery",
-                           "description": "user:test",
-                           "time_in_nanos": "303702",
-                           "breakdown": {
-                              "score": 0,
-                              "build_scorer_count": 1,
-                              "match_count": 0,
-                              "create_weight": 185215,
-                              "next_doc": 5936,
-                              "match": 0,
-                              "create_weight_count": 1,
-                              "next_doc_count": 2,
-                              "score_count": 1,
-                              "build_scorer": 112551,
-                              "advance": 0,
-                              "advance_count": 0,
-                              "compute_max_score": 0,
-                              "compute_max_score_count": 0,
-                              "shallow_advance": 0,
-                              "shallow_advance_count": 0,
-                              "set_min_competitive_score": 0,
-                              "set_min_competitive_score_count": 0
-                           }
-                        }
-                     ],
-                     "rewrite_time": 7208,
-                     "collector": [
-                        {
-                          "name": "MultiCollector",
-                          "reason": "search_multi",
-                          "time_in_nanos": 1820,
-                          "children": [
-                            {
-                              "name": "FilteredCollector",
-                              "reason": "search_post_filter",
-                              "time_in_nanos": 7735,
-                              "children": [
-                                {
-                                  "name": "SimpleTopScoreDocCollector",
-                                  "reason": "search_top_hits",
-                                  "time_in_nanos": 1328
-                                }
-                              ]
-                            },
-                            {
-                              "name": "MultiBucketCollector: [[my_scoped_agg, my_global_agg]]",
-                              "reason": "aggregation",
-                              "time_in_nanos": 8273
-                            }
-                          ]
-                        }
-                     ]
+                    "name": "MultiBucketCollector: [[my_scoped_agg, my_global_agg]]",
+                    "reason": "aggregation",
+                    "time_in_nanos": 867617
                   }
-               ],
-               "aggregations": [...] <1>
-            }
-         ]
+                ]
+              }
+            ]
+          }
+        ],
+        "aggregations": [...] <1>
       }
+    ]
+  }
 }
 --------------------------------------------------
 // TESTRESPONSE[s/"aggregations": \[\.\.\.\]/"aggregations": $body.$_path/]
 // TESTRESPONSE[s/\.\.\.//]
 // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
-// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[test\]\[0\]"/"id": $body.profile.shards.0.id/]
+// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[my-index-000001\]\[0\]"/"id": $body.profile.shards.0.id/]
 <1> The `"aggregations"` portion has been omitted because it will be covered in 
 the next section.
 
 As you can see, the output is significantly more verbose than before.  All the 
 major portions of the query are represented:
 
-1. The first `TermQuery` (user:test) represents the main `term` query.
-2. The second `TermQuery` (message:some) represents the `post_filter` query.
+1. The first `TermQuery` (user.id:elkbee) represents the main `term` query.
+2. The second `TermQuery` (message:search) represents the `post_filter` query.
 
 The Collector tree is fairly straightforward, showing how a single 
 CancellableCollector wraps a MultiCollector which also wraps a FilteredCollector 
@@ -734,20 +735,20 @@ and look at the aggregation profile this time:
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "profile": true,
   "query": {
     "term": {
-      "user": {
-        "value": "test"
+      "user.id": {
+        "value": "elkbee"
       }
     }
   },
   "aggs": {
     "my_scoped_agg": {
       "terms": {
-        "field": "likes"
+        "field": "http.response.status_code"
       }
     },
     "my_global_agg": {
@@ -755,7 +756,7 @@ GET /twitter/_search
       "aggs": {
         "my_level_agg": {
           "terms": {
-            "field": "likes"
+            "field": "http.response.status_code"
           }
         }
       }
@@ -763,7 +764,7 @@ GET /twitter/_search
   },
   "post_filter": {
     "match": {
-      "message": "some"
+      "message": "search"
     }
   }
 }
@@ -777,61 +778,61 @@ This yields the following aggregation profile output:
 [source,console-result]
 --------------------------------------------------
 {
-  "profile" : {
-    "shards" : [
+  "profile": {
+    "shards": [
       {
-        "aggregations" : [
+        "aggregations": [
           {
-            "type" : "NumericTermsAggregator",
-            "description" : "my_scoped_agg",
-            "time_in_nanos" : 195386,
-            "breakdown" : {
-              "reduce" : 0,
-              "build_aggregation" : 81171,
-              "build_aggregation_count" : 1,
-              "initialize" : 22753,
-              "initialize_count" : 1,
-              "reduce_count" : 0,
-              "collect" : 91456,
-              "collect_count" : 4
+            "type": "NumericTermsAggregator",
+            "description": "my_scoped_agg",
+            "time_in_nanos": 79294,
+            "breakdown": {
+              "reduce": 0,
+              "build_aggregation": 30885,
+              "build_aggregation_count": 1,
+              "initialize": 2623,
+              "initialize_count": 1,
+              "reduce_count": 0,
+              "collect": 45786,
+              "collect_count": 4
             },
             "debug": {
-              "result_strategy": "long_terms",
-              "total_buckets": 4
+              "total_buckets": 1,
+              "result_strategy": "long_terms"
             }
           },
           {
-            "type" : "GlobalAggregator",
-            "description" : "my_global_agg",
-            "time_in_nanos" : 190430,
-            "breakdown" : {
-              "reduce" : 0,
-              "build_aggregation" : 59990,
-              "build_aggregation_count" : 1,
-              "initialize" : 29619,
-              "initialize_count" : 1,
-              "reduce_count" : 0,
-              "collect" : 100815,
-              "collect_count" : 4
+            "type": "GlobalAggregator",
+            "description": "my_global_agg",
+            "time_in_nanos": 104325,
+            "breakdown": {
+              "reduce": 0,
+              "build_aggregation": 22470,
+              "build_aggregation_count": 1,
+              "initialize": 12454,
+              "initialize_count": 1,
+              "reduce_count": 0,
+              "collect": 69401,
+              "collect_count": 4
             },
-            "children" : [
+            "children": [
               {
-                "type" : "NumericTermsAggregator",
-                "description" : "my_level_agg",
-                "time_in_nanos" : 160329,
-                "breakdown" : {
-                  "reduce" : 0,
-                  "build_aggregation" : 55712,
-                  "build_aggregation_count" : 1,
-                  "initialize" : 10559,
-                  "initialize_count" : 1,
-                  "reduce_count" : 0,
-                  "collect" : 94052,
-                  "collect_count" : 4,
+                "type": "NumericTermsAggregator",
+                "description": "my_level_agg",
+                "time_in_nanos": 76876,
+                "breakdown": {
+                  "reduce": 0,
+                  "build_aggregation": 13824,
+                  "build_aggregation_count": 1,
+                  "initialize": 1441,
+                  "initialize_count": 1,
+                  "reduce_count": 0,
+                  "collect": 61611,
+                  "collect_count": 4
                 },
                 "debug": {
-                  "result_strategy": "long_terms",
-                  "total_buckets": 4
+                  "total_buckets": 1,
+                  "result_strategy": "long_terms"
                 }
               }
             ]
@@ -844,13 +845,13 @@ This yields the following aggregation profile output:
 --------------------------------------------------
 // TESTRESPONSE[s/\.\.\.//]
 // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
-// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[test\]\[0\]"/"id": $body.profile.shards.0.id/]
+// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[my-index-000001\]\[0\]"/"id": $body.profile.shards.0.id/]
 
 From the profile structure we can see that the `my_scoped_agg` is internally 
 being run as a `NumericTermsAggregator` (because the field it is aggregating, 
-`likes`, is a numeric field). At the same level, we see a `GlobalAggregator` 
+`http.response.status_code`, is a numeric field). At the same level, we see a `GlobalAggregator` 
 which comes from `my_global_agg`. That aggregation then has a child 
-`NumericTermsAggregator` which comes from the second term's aggregation on `likes`.
+`NumericTermsAggregator` which comes from the second term's aggregation on `http.response.status_code`.
 
 The `time_in_nanos` field shows the time executed by each aggregation, and is 
 inclusive of all children.  While the overall time is useful, the `breakdown` 
@@ -870,14 +871,13 @@ The `breakdown` component lists detailed statistics about low-level execution:
 --------------------------------------------------
 "breakdown": {
   "reduce": 0,
+  "build_aggregation": 30885,
+  "build_aggregation_count": 1,
+  "initialize": 2623,
+  "initialize_count": 1,
   "reduce_count": 0,
-  "build_aggregation": 49765,
-  "build_aggregation_count": 300,
-  "initialize": 52785,
-  "initialize_count": 300,
-  "reduce_count": 0,
-  "collect": 3155490036,
-  "collect_count": 1800
+  "collect": 45786,
+  "collect_count": 4
 }
 --------------------------------------------------
 // NOTCONSOLE

docs/reference/search/rank-eval.asciidoc

@@ -230,7 +230,7 @@ that contains one relevant result in position 1.
 
 [source,console]
 --------------------------------
-GET /twitter/_rank_eval
+GET /my-index-000001/_rank_eval
 {
   "requests": [
     {
@@ -247,7 +247,7 @@ GET /twitter/_rank_eval
   }
 }
 --------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The `precision` metric takes the following optional parameters
 
@@ -285,7 +285,7 @@ that contains one relevant result in position 1.
 
 [source,console]
 --------------------------------
-GET /twitter/_rank_eval
+GET /my-index-000001/_rank_eval
 {
   "requests": [
     {
@@ -301,7 +301,7 @@ GET /twitter/_rank_eval
   }
 }
 --------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The `recall` metric takes the following optional parameters
 
@@ -326,7 +326,7 @@ https://en.wikipedia.org/wiki/Mean_reciprocal_rank[mean reciprocal rank].
 
 [source,console]
 --------------------------------
-GET /twitter/_rank_eval
+GET /my-index-000001/_rank_eval
 {
   "requests": [
     {
@@ -342,7 +342,7 @@ GET /twitter/_rank_eval
   }
 }
 --------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The `mean_reciprocal_rank` metric takes the following optional parameters
 
@@ -370,7 +370,7 @@ the overall DCG metric.
 
 [source,console]
 --------------------------------
-GET /twitter/_rank_eval
+GET /my-index-000001/_rank_eval
 {
   "requests": [
     {
@@ -386,7 +386,7 @@ GET /twitter/_rank_eval
   }
 }
 --------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The `dcg` metric takes the following optional parameters:
 
@@ -426,7 +426,7 @@ for.
 
 [source,console]
 --------------------------------
-GET /twitter/_rank_eval
+GET /my-index-000001/_rank_eval
 {
   "requests": [
     {
@@ -442,7 +442,7 @@ GET /twitter/_rank_eval
   }
 }
 --------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The `expected_reciprocal_rank` metric takes the following parameters:
 

docs/reference/search/request-body.asciidoc

@@ -5,14 +5,14 @@ Specifies search criteria as request body parameters.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "query" : {
-    "term" : { "user" : "kimchy" }
+    "term" : { "user.id" : "kimchy" }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 [[search-request-body-api-request]]
@@ -63,9 +63,9 @@ matching document was found (per shard).
 
 [source,console]
 --------------------------------------------------
-GET /_search?q=message:number&size=0&terminate_after=1
+GET /_search?q=user.id:elkbee&size=0&terminate_after=1
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 The response will not contain any hits as the `size` was set to `0`. The

docs/reference/search/request/collapse.asciidoc

@@ -3,29 +3,31 @@
 
 You can use the `collapse` parameter to collapse search results based
 on field values. The collapsing is done by selecting only the top sorted
-document per collapse key. For instance the query below retrieves the best tweet
-for each user and sorts them by number of likes.
+document per collapse key.
+
+For example, the following search collapses results by `user.id` and sorts them
+by `http.response.bytes`.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "message": "GET /search"
     }
   },
   "collapse": {
-    "field": "user"     <1>
+    "field": "user.id"                <1>
   },
-  "sort": [ "likes" ],  <2>
-  "from": 10            <3>
+  "sort": [ "http.response.bytes" ],  <2>
+  "from": 10                          <3>
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
-<1> collapse the result set using the "user" field
-<2> sort the top docs by number of likes
+<1> Collapse the result set using the "user.id" field
+<2> Sort the results by `http.response.bytes`
 <3> define the offset of the first collapsed result
 
 WARNING: The total number of hits in the response indicates the number of matching documents without collapsing.
@@ -43,32 +45,32 @@ It is also possible to expand each collapsed top hits with the `inner_hits` opti
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "message": "GET /search"
     }
   },
   "collapse": {
-    "field": "user",                    <1>
+    "field": "user.id",                       <1>
     "inner_hits": {
-      "name": "last_tweets",            <2>
-      "size": 5,                        <3>
-      "sort": [ { "date": "asc" } ]     <4>
+      "name": "most_recent",                  <2>
+      "size": 5,                              <3>
+      "sort": [ { "@timestamp": "asc" } ]     <4>
     },
-    "max_concurrent_group_searches": 4  <5>
+    "max_concurrent_group_searches": 4        <5>
   },
-  "sort": [ "likes" ]
+  "sort": [ "http.response.bytes" ]
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
-<1> collapse the result set using the "user" field
+<1> collapse the result set using the "user.id" field
 <2> the name used for the inner hit section in the response
 <3> the number of inner_hits to retrieve per collapse key
 <4> how to sort the document inside each group
-<5> the number of concurrent requests allowed to retrieve the inner_hits` per group
+<5> the number of concurrent requests allowed to retrieve the `inner_hits` per group
 
 See <<request-body-search-inner-hits, inner hits>> for the complete list of supported options and the format of the response.
 
@@ -77,36 +79,36 @@ multiple representations of the collapsed hits.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "message": "GET /search"
     }
   },
   "collapse": {
-    "field": "user",                  <1>
+    "field": "user.id",                      <1>
       "inner_hits": [
       {
-        "name": "most_liked",         <2>
+        "name": "largest_responses",         <2>
         "size": 3,
-        "sort": [ "likes" ]
+        "sort": [ "http.response.bytes" ]
       },
       {
-        "name": "most_recent",        <3>
+        "name": "most_recent",               <3>
         "size": 3,
-        "sort": [ { "date": "asc" } ]
+        "sort": [ { "@timestamp": "asc" } ]
       }
     ]
   },
-  "sort": [ "likes" ]
+  "sort": [ "http.response.bytes" ]
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
-<1> collapse the result set using the "user" field
-<2> return the three most liked tweets for the user
-<3> return the three most recent tweets for the user
+<1> collapse the result set using the "user.id" field
+<2> return the three largest HTTP responses for the user
+<3> return the three most recent HTTP responses for the user
 
 The expansion of the group is done by sending an additional query for each
 `inner_hit` request for each collapsed hit returned in the response.  This can significantly slow things down
@@ -124,24 +126,24 @@ WARNING: `collapse` cannot be used in conjunction with <<scroll-search-results,
 === Second level of collapsing
 
 Second level of collapsing is also supported and is applied to `inner_hits`.
-For example, the following request finds the top scored tweets for
-each country, and within each country finds the top scored tweets
-for each user.
+
+For example, the following search collapses results by `geo.country_name`.
+Within each `geo.country_name`, inner hits are collapsed by `user.id`.
 
 [source,js]
 --------------------------------------------------
-GET /twitter/_search
+GET /my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "message": "GET /search"
     }
   },
   "collapse": {
-    "field": "country",
+    "field": "geo.country_name",
     "inner_hits": {
       "name": "by_location",
-      "collapse": { "field": "user" },
+      "collapse": { "field": "user.id" },
       "size": 3
     }
   }
@@ -157,12 +159,12 @@ Response:
   ...
   "hits": [
     {
-      "_index": "twitter",
+      "_index": "my-index-000001",
       "_type": "_doc",
       "_id": "9",
       "_score": ...,
       "_source": {...},
-      "fields": { "country": [ "UK" ] },
+      "fields": { "geo": { "country_name": [ "UK" ] }},
       "inner_hits": {
         "by_location": {
           "hits": {
@@ -170,15 +172,15 @@ Response:
             "hits": [
               {
                 ...
-                "fields": { "user": [ "user124" ] }
+                "fields": { "user": "id": { [ "user124" ] }}
               },
               {
                 ...
-                "fields": { "user": [ "user589" ] }
+                "fields": { "user": "id": { [ "user589" ] }}
               },
               {
                 ...
-                "fields": { "user": [ "user001" ] }
+                "fields": { "user": "id": { [ "user001" ] }}
               }
             ]
           }
@@ -186,13 +188,13 @@ Response:
       }
     },
     {
-      "_index": "twitter",
+      "_index": "my-index-000001",
       "_type": "_doc",
       "_id": "1",
       "_score": ..,
       "_source": {...
       },
-      "fields": { "country": [ "Canada" ] },
+      "fields": { "geo": { "country_name": [ "Canada" ] }},
       "inner_hits": {
         "by_location": {
           "hits": {
@@ -200,15 +202,15 @@ Response:
             "hits": [
               {
                 ...
-                "fields": { "user": [ "user444" ] }
+                "fields": { "user": "id": { [ "user444" ] }}
               },
               {
                 ...
-                "fields": { "user": [ "user1111" ] }
+                "fields": { "user": "id": { [ "user1111" ] }
               },
               {
                 ...
-                  "fields": { "user": [ "user999" ] }
+                  "fields": { "user": "id": { [ "user999" ] }}
               }
             ]
           }

docs/reference/search/request/highlighting.asciidoc

@@ -34,7 +34,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 {es} supports three highlighters: `unified`, `plain`, and `fvh` (fast vector
 highlighter). You can specify the highlighter `type` you want to use
@@ -286,7 +286,7 @@ individual fields.
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "number_of_fragments" : 3,
@@ -300,7 +300,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [discrete]
 [[specify-highlight-query]]
@@ -369,7 +369,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [discrete]
 [[set-highlighter-type]]
@@ -384,7 +384,7 @@ The following is an example that forces the use of the plain highlighter:
 GET /_search
 {
   "query": {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight": {
     "fields": {
@@ -393,7 +393,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [[configure-tags]]
 [discrete]
@@ -408,7 +408,7 @@ for example:
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "pre_tags" : ["<tag1>"],
@@ -419,7 +419,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 When using the fast vector highlighter, you can specify additional tags and the
 "importance" is ordered.
@@ -429,7 +429,7 @@ When using the fast vector highlighter, you can specify additional tags and the
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "pre_tags" : ["<tag1>", "<tag2>"],
@@ -440,7 +440,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 You can also use the built-in `styled` tag schema:
 
@@ -449,7 +449,7 @@ You can also use the built-in `styled` tag schema:
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "tags_schema" : "styled",
@@ -459,7 +459,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [discrete]
 [[highlight-source]]
@@ -473,7 +473,7 @@ are stored separately. Defaults to `false`.
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "fields" : {
@@ -482,7 +482,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 [[highlight-all]]
@@ -497,7 +497,7 @@ By default, only fields that contains a query match are highlighted. Set
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "require_field_match": false,
@@ -507,7 +507,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [[matched-fields]]
 [discrete]
@@ -546,7 +546,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The above matches both "run with scissors" and "running with scissors"
 and would highlight "running" and "scissors" but not "run". If both
@@ -575,7 +575,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The above highlights "run" as well as "running" and "scissors" but
 still sorts "running with scissors" above "run with scissors" because
@@ -602,7 +602,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The above query wouldn't highlight "run" or "scissor" but shows that
 it is just fine not to list the field to which the matches are combined
@@ -662,7 +662,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 None of the highlighters built into Elasticsearch care about the order that the
 fields are highlighted but a plugin might.
@@ -684,7 +684,7 @@ For example:
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "fields" : {
@@ -693,7 +693,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 On top of this it is possible to specify that highlighted fragments need
 to be sorted by score:
@@ -703,7 +703,7 @@ to be sorted by score:
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "order" : "score",
@@ -713,7 +713,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 If the `number_of_fragments` value is set to `0` then no fragments are
 produced, instead the whole content of the field is returned, and of
@@ -726,7 +726,7 @@ is required. Note that `fragment_size` is ignored in this case.
 GET /_search
 {
   "query" : {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight" : {
     "fields" : {
@@ -736,7 +736,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 When using `fvh` one can use `fragment_offset`
 parameter to control the margin to start highlighting from.
@@ -752,7 +752,7 @@ specified as it tries to break on a word boundary.
 GET /_search
 {
   "query": {
-    "match": { "user": "kimchy" }
+    "match": { "user.id": "kimchy" }
   },
   "highlight": {
     "fields": {
@@ -765,7 +765,7 @@ GET /_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [discrete]
 [[highlight-postings-list]]
@@ -816,7 +816,7 @@ When using the `plain` highlighter, you can choose between the `simple` and
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "query": {
     "match_phrase": { "message": "number 1" }
@@ -833,7 +833,7 @@ GET twitter/_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 Response:
 
@@ -849,14 +849,11 @@ Response:
     "max_score": 1.6011951,
     "hits": [
       {
-        "_index": "twitter",
+        "_index": "my-index-000001",
         "_id": "1",
         "_score": 1.6011951,
         "_source": {
-          "user": "test",
-          "message": "some message with the number 1",
-          "date": "2009-11-15T14:12:12",
-          "likes": 1
+          "message": "some message with the number 1"
         },
         "highlight": {
           "message": [
@@ -873,7 +870,7 @@ Response:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "query": {
     "match_phrase": { "message": "number 1" }
@@ -890,7 +887,7 @@ GET twitter/_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 Response:
 
@@ -906,14 +903,11 @@ Response:
     "max_score": 1.6011951,
     "hits": [
       {
-        "_index": "twitter",
+        "_index": "my-index-000001",
         "_id": "1",
         "_score": 1.6011951,
         "_source": {
-          "user": "test",
-          "message": "some message with the number 1",
-          "date": "2009-11-15T14:12:12",
-          "likes": 1
+          "message": "some message with the number 1"
         },
         "highlight": {
           "message": [

docs/reference/search/request/rescore.asciidoc

@@ -68,7 +68,7 @@ POST /_search
    }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The way the scores are combined can be controlled with the `score_mode`:
 [cols="<,<",options="header",]
@@ -120,7 +120,7 @@ POST /_search
             "function_score" : {
                "script_score": {
                   "script": {
-                    "source": "Math.log10(doc.likes.value + 2)"
+                    "source": "Math.log10(doc.count.value + 2)"
                   }
                }
             }
@@ -129,7 +129,7 @@ POST /_search
    } ]
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The first one gets the results of the query then the second one gets the
 results of the first, etc.  The second rescore will "see" the sorting done

docs/reference/search/request/script-fields.asciidoc

@@ -54,7 +54,7 @@ GET /_search
         }
     }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 Note the `_source` keyword here to navigate the json-like model.
 

docs/reference/search/request/scroll.asciidoc

@@ -44,17 +44,17 @@ should keep the ``search context'' alive (see <<scroll-search-context>>), eg `?s
 
 [source,console]
 --------------------------------------------------
-POST /twitter/_search?scroll=1m
+POST /my-index-000001/_search?scroll=1m
 {
   "size": 100,
   "query": {
     "match": {
-      "title": "elasticsearch"
+      "message": "foo"
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The result from the above request includes a `_scroll_id`, which should
 be passed to the `scroll` API in order to retrieve the next batch of
@@ -101,7 +101,7 @@ GET /_search?scroll=1m
   ]
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [discrete]
 [[scroll-search-context]]
@@ -209,7 +209,7 @@ can be consumed independently:
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search?scroll=1m
+GET /my-index-000001/_search?scroll=1m
 {
   "slice": {
     "id": 0,                      <1>
@@ -217,11 +217,11 @@ GET /twitter/_search?scroll=1m
   },
   "query": {
     "match": {
-      "title": "elasticsearch"
+      "message": "foo"
     }
   }
 }
-GET /twitter/_search?scroll=1m
+GET /my-index-000001/_search?scroll=1m
 {
   "slice": {
     "id": 1,
@@ -229,12 +229,12 @@ GET /twitter/_search?scroll=1m
   },
   "query": {
     "match": {
-      "title": "elasticsearch"
+      "message": "foo"
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:big_twitter]
+// TEST[setup:my_index_big]
 
 <1> The id of the slice
 <2> The maximum number of slices
@@ -271,21 +271,21 @@ slice gets deterministic results.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search?scroll=1m
+GET /my-index-000001/_search?scroll=1m
 {
   "slice": {
-    "field": "date",
+    "field": "@timestamp",
     "id": 0,
     "max": 10
   },
   "query": {
     "match": {
-      "title": "elasticsearch"
+      "message": "foo"
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:big_twitter]
+// TEST[setup:my_index_big]
 
 For append only time-based indices, the `timestamp` field can be used safely.
 

docs/reference/search/request/search-after.asciidoc

@@ -13,21 +13,21 @@ Suppose that the query to retrieve the first page looks like this:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "size": 10,
   "query": {
     "match" : {
-      "title" : "elasticsearch"
+      "message" : "foo"
     }
   },
   "sort": [
-    {"date": "asc"},
+    {"@timestamp": "asc"},
     {"tie_breaker_id": "asc"}      <1>
   ]
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 // TEST[s/"tie_breaker_id": "asc"/"tie_breaker_id": {"unmapped_type": "keyword"}/]
 
 <1> A copy of the `_id` field with `doc_values` enabled
@@ -56,22 +56,22 @@ For instance we can use the `sort values` of the last document and pass it to `s
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "size": 10,
   "query": {
     "match" : {
-      "title" : "elasticsearch"
+      "message" : "foo"
     }
   },
   "search_after": [1463538857, "654323"],
   "sort": [
-    {"date": "asc"},
+    {"@timestamp": "asc"},
     {"tie_breaker_id": "asc"}
   ]
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 // TEST[s/"tie_breaker_id": "asc"/"tie_breaker_id": {"unmapped_type": "keyword"}/]
 
 NOTE: The parameter `from` must be set to 0 (or -1) when `search_after` is used.

docs/reference/search/request/search-type.asciidoc

@@ -52,9 +52,9 @@ shards*.
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search?search_type=query_then_fetch
+GET my-index-000001/_search?search_type=query_then_fetch
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 NOTE: This is the default setting, if you do not specify a `search_type`
       in your request.
@@ -70,6 +70,6 @@ scoring.
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search?search_type=dfs_query_then_fetch
+GET my-index-000001/_search?search_type=dfs_query_then_fetch
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]

docs/reference/search/request/track-total-hits.asciidoc

@@ -21,17 +21,17 @@ that `"total.value"` is the accurate count.
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "track_total_hits": true,
     "query": {
       "match" : {
-        "message" : "Elasticsearch"
+        "user.id" : "elkbee"
       }
     }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 \... returns:
 
@@ -66,12 +66,12 @@ the query up to 100 documents:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "track_total_hits": 100,
   "query": {
     "match": {
-      "message": "Elasticsearch"
+      "user.id": "elkbee"
     }
   }
 }
@@ -140,12 +140,12 @@ times by setting this option to `false`:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_search
+GET my-index-000001/_search
 {
   "track_total_hits": false,
   "query": {
     "match": {
-      "message": "Elasticsearch"
+      "user.id": "elkbee"
     }
   }
 }

docs/reference/search/scroll-api.asciidoc

@@ -18,7 +18,7 @@ GET /_search?scroll=1m
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 ////
 
 [source,console]

docs/reference/search/search-fields.asciidoc

@@ -9,18 +9,18 @@ response, you can use the `fields` parameter:
 
 [source,console]
 ----
-POST twitter/_search
+POST my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "message": "foo"
     }
   },
-  "fields": ["user", "date"],
+  "fields": ["user.id", "@timestamp"],
   "_source": false
 }
 ----
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 The `fields` parameter consults both a document's `_source` and the index
 mappings to load and return values. Because it makes use of the mappings,
@@ -60,30 +60,30 @@ type. By default, date fields are formatted according to the
 <<mapping-date-format,date format>> parameter in their mappings.
 
 The following search request uses the `fields` parameter to retrieve values
-for the `user` field, all fields starting with `location.`, and the
-`date` field:
+for the `user.id` field, all fields starting with `http.response.`, and the
+`@timestamp` field:
 
 [source,console]
 ----
-POST twitter/_search
+POST my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "user.id": "kimchy"
     }
   },
   "fields": [
-    "user",
-    "location.*", <1>
+    "user.id",
+    "http.response.*", <1>
     {
-      "field": "date",
+      "field": "@timestamp",
       "format": "epoch_millis" <2>
     }
   ],
   "_source": false
 }
 ----
-// TEST[continued]
+// TEST[setup:my_index]
 
 <1> Both full field names and wildcard patterns are accepted.
 <2> Using object notation, you can pass a `format` parameter to apply a custom
@@ -116,21 +116,21 @@ The values are returned as a flat list in the `fields` section in each hit:
     "max_score" : 1.0,
     "hits" : [
       {
-        "_index" : "twitter",
+        "_index" : "my-index-000001",
         "_id" : "0",
         "_score" : 1.0,
         "fields" : {
-          "user" : [
+          "user.id" : [
             "kimchy"
           ],
-          "date" : [
-            "1258294332000"
+          "@timestamp" : [
+            "4098435132000"
           ],
-          "location.city": [
-            "Amsterdam"
+          "http.response.bytes": [
+            1070000
           ],
-          "location.country": [
-            "Netherlands"
+          "http.response.status_code": [
+            200
           ]
         }
       }
@@ -177,21 +177,21 @@ not supported for <<text,`text`>> or
 {plugins}/mapper-annotated-text-usage.html[`text_annotated`] fields.
 
 The following search request uses the `docvalue_fields` parameter to retrieve
-doc values for the `user` field, all fields starting with `location.`, and the
-`date` field:
+doc values for the `user.id` field, all fields starting with `http.response.`, and the
+`@timestamp` field:
 
 [source,console]
 ----
-GET twitter/_search
+GET my-index-000001/_search
 {
   "query": {
     "match": {
-      "message": "elasticsearch"
+      "user.id": "kimchy"
     }
   },
   "docvalue_fields": [
-    "user",
-    "location.*", <1>
+    "user.id",
+    "http.response.*", <1>
     {
       "field": "date",
       "format": "epoch_millis" <2>
@@ -199,7 +199,7 @@ GET twitter/_search
   ]
 }
 ----
-// TEST[continued]
+// TEST[setup:my_index]
 
 <1> Both full field names and wildcard patterns are accepted.
 <2> Using object notation, you can pass a `format` parameter to apply a custom

docs/reference/search/search-shards.asciidoc

@@ -5,9 +5,9 @@ Returns the indices and shards that a search request would be executed against.
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search_shards
+GET /my-index-000001/_search_shards
 --------------------------------------------------
-// TEST[s/^/PUT twitter\n{"settings":{"index.number_of_shards":5}}\n/]
+// TEST[s/^/PUT my-index-000001\n{"settings":{"index.number_of_shards":5}}\n/]
 
 
 [[search-shards-api-request]]
@@ -58,9 +58,9 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=routing]
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search_shards
+GET /my-index-000001/_search_shards
 --------------------------------------------------
-// TEST[s/^/PUT twitter\n{"settings":{"index.number_of_shards":5}}\n/]
+// TEST[s/^/PUT my-index-000001\n{"settings":{"index.number_of_shards":5}}\n/]
 
 The API returns the following result:
 
@@ -69,12 +69,12 @@ The API returns the following result:
 {
   "nodes": ...,
   "indices" : {
-    "twitter": { }
+    "my-index-000001": { }
   },
   "shards": [
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 0,
@@ -85,7 +85,7 @@ The API returns the following result:
     ],
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 1,
@@ -96,7 +96,7 @@ The API returns the following result:
     ],
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 2,
@@ -107,7 +107,7 @@ The API returns the following result:
     ],
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 3,
@@ -118,7 +118,7 @@ The API returns the following result:
     ],
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 4,
@@ -142,9 +142,9 @@ Specifying the same request, this time with a routing value:
 
 [source,console]
 --------------------------------------------------
-GET /twitter/_search_shards?routing=foo,bar
+GET /my-index-000001/_search_shards?routing=foo,bar
 --------------------------------------------------
-// TEST[s/^/PUT twitter\n{"settings":{"index.number_of_shards":5}}\n/]
+// TEST[s/^/PUT my-index-000001\n{"settings":{"index.number_of_shards":5}}\n/]
 
 The API returns the following result:
 
@@ -153,12 +153,12 @@ The API returns the following result:
 {
   "nodes": ...,
   "indices" : {
-      "twitter": { }
+      "my-index-000001": { }
   },
   "shards": [
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 2,
@@ -169,7 +169,7 @@ The API returns the following result:
     ],
     [
       {
-        "index": "twitter",
+        "index": "my-index-000001",
         "node": "JklnKbD7Tyqi9TP3_Q_tBg",
         "primary": true,
         "shard": 3,

docs/reference/search/search-template.asciidoc

@@ -13,12 +13,12 @@ GET _search/template
   },
   "params" : {
     "my_field" : "message",
-    "my_value" : "some message",
+    "my_value" : "foo",
     "my_size" : 5
   }
 }
 ------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [[search-template-api-request]]
 ==== {api-request-title}
@@ -306,7 +306,7 @@ GET _search/template
   }
 }
 ------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 [[search-template-converting-to-json]]
 ===== Converting parameters to JSON

docs/reference/search/suggesters.asciidoc

@@ -6,7 +6,7 @@ Parts of the suggest feature are still under development.
 
 [source,console]
 --------------------------------------------------
-POST twitter/_search
+POST my-index-000001/_search
 {
   "query" : {
     "match": {
@@ -23,7 +23,7 @@ POST twitter/_search
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 
 [[search-suggesters-api-request]]
@@ -61,14 +61,14 @@ POST _search
     "my-suggest-2" : {
       "text" : "kmichy",
       "term" : {
-        "field" : "user"
+        "field" : "user.id"
       }
     }
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
-
+// TEST[setup:messages]
+// TEST[s/^/PUT my-index-000001\/_mapping\n{"properties":{"user":{"properties":{"id":{"type":"keyword"}}}}}\n/]
 
 The below suggest response example includes the suggestion response for
 `my-suggest-1` and `my-suggest-2`. Each suggestion part contains

docs/reference/search/suggesters/misc.asciidoc

@@ -25,7 +25,7 @@ POST _search?typed_keys
   }
 }
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:messages]
 
 In the response, the suggester names will be changed to respectively `term#my-first-suggester` and
 `phrase#my-second-suggester`, reflecting the types of each suggestion:

docs/reference/search/validate.asciidoc

@@ -5,9 +5,9 @@ Validates a potentially expensive query without executing it.
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query?q=user:foo
+GET my-index-000001/_validate/query?q=user.id:kimchy
 --------------------------------------------------
-// TEST[setup:twitter]
+// TEST[setup:my_index]
 
 
 [[search-validate-api-request]]
@@ -79,11 +79,11 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=search-q]
 
 [source,console]
 --------------------------------------------------
-PUT twitter/_bulk?refresh
+PUT my-index-000001/_bulk?refresh
 {"index":{"_id":1}}
-{"user" : "kimchy", "post_date" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"}
+{"user" : { "id": "kimchy" }, "@timestamp" : "2099-11-15T14:12:12", "message" : "trying out Elasticsearch"}
 {"index":{"_id":2}}
-{"user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"}
+{"user" : { "id": "kimchi" }, "@timestamp" : "2099-11-15T14:12:13", "message" : "My user ID is similar to kimchy!"}
 --------------------------------------------------
 
 
@@ -91,7 +91,7 @@ When sent a valid query:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query?q=user:foo
+GET my-index-000001/_validate/query?q=user.id:kimchy
 --------------------------------------------------
 // TEST[continued]
 
@@ -108,7 +108,7 @@ The query may also be sent in the request body:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query
+GET my-index-000001/_validate/query
 {
   "query" : {
     "bool" : {
@@ -118,7 +118,7 @@ GET twitter/_validate/query
         }
       },
       "filter" : {
-        "term" : { "user" : "kimchy" }
+        "term" : { "user.id" : "kimchy" }
       }
     }
   }
@@ -135,11 +135,11 @@ mapping, and 'foo' does not correctly parse into a date:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query
+GET my-index-000001/_validate/query
 {
   "query": {
     "query_string": {
-      "query": "post_date:foo",
+      "query": "@timestamp:foo",
       "lenient": false
     }
   }
@@ -159,11 +159,11 @@ why a query failed:
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query?explain=true
+GET my-index-000001/_validate/query?explain=true
 {
   "query": {
     "query_string": {
-      "query": "post_date:foo",
+      "query": "@timestamp:foo",
       "lenient": false
     }
   }
@@ -184,9 +184,9 @@ The API returns the following response:
     "failed" : 0
   },
   "explanations" : [ {
-    "index" : "twitter",
+    "index" : "my-index-000001",
     "valid" : false,
-    "error" : "twitter/IAEc2nIXSSunQA_suI0MLw] QueryShardException[failed to create query:...failed to parse date field [foo]"
+    "error" : "my-index-000001/IAEc2nIXSSunQA_suI0MLw] QueryShardException[failed to create query:...failed to parse date field [foo]"
   } ]
 }
 --------------------------------------------------
@@ -200,7 +200,7 @@ showing the actual Lucene query that will be executed.
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query?rewrite=true
+GET my-index-000001/_validate/query?rewrite=true
 {
   "query": {
     "more_like_this": {
@@ -228,7 +228,7 @@ The API returns the following response:
    },
    "explanations": [
       {
-         "index": "twitter",
+         "index": "my-index-000001",
          "valid": true,
          "explanation": "((user:terminator^3.71334 plot:future^2.763601 plot:human^2.8415773 plot:sarah^3.4193945 plot:kyle^3.8244398 plot:cyborg^3.9177752 plot:connor^4.040236 plot:reese^4.7133346 ... )~6) -ConstantScore(_id:2)) #(ConstantScore(_type:_doc))^0.0"
       }
@@ -248,21 +248,21 @@ all available shards.
 ////
 [source,console]
 --------------------------------------------------
-PUT twitter/_bulk?refresh
+PUT my-index-000001/_bulk?refresh
 {"index":{"_id":1}}
-{"user" : "kimchy", "post_date" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"}
+{"user" : { "id": "kimchy" }, "@timestamp" : "2099-11-15T14:12:12", "message" : "trying out Elasticsearch"}
 {"index":{"_id":2}}
-{"user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"}
+{"user" : { "id": "kimchi" }, "@timestamp" : "2099-11-15T14:12:13", "message" : "My user ID is similar to kimchy!"}
 --------------------------------------------------
 ////
 
 [source,console]
 --------------------------------------------------
-GET twitter/_validate/query?rewrite=true&all_shards=true
+GET my-index-000001/_validate/query?rewrite=true&all_shards=true
 {
   "query": {
     "match": {
-      "user": {
+      "user.id": {
         "query": "kimchy",
         "fuzziness": "auto"
       }
@@ -285,10 +285,10 @@ The API returns the following response:
   },
   "explanations": [
     {
-      "index": "twitter",
+      "index": "my-index-000001",
       "shard": 0,
       "valid": true,
-      "explanation": "(user:kimchi)^0.8333333 user:kimchy"
+      "explanation": "(user.id:kimchi)^0.8333333 user.id:kimchy"
     }
   ]
 }