Merge branch 'master' into java-time

Author: spinscale

client/rest-high-level/src/main/java/org/elasticsearch/client/watcher/WatchStatus.java

@@ -26,6 +26,7 @@
 import org.joda.time.DateTime;
 
 import java.io.IOException;
+import java.util.Collections;
 import java.util.HashMap;
 import java.util.Map;
 import java.util.Objects;
@@ -125,7 +126,7 @@ public static WatchStatus parse(XContentParser parser) throws IOException {
         DateTime lastChecked = null;
         DateTime lastMetCondition = null;
         Map<String, ActionStatus> actions = null;
-        Map<String, String> headers = null;
+        Map<String, String> headers = Collections.emptyMap();
         long version = -1;
 
         ensureExpectedToken(XContentParser.Token.START_OBJECT, parser.currentToken(), parser::getTokenLocation);

distribution/packages/build.gradle

@@ -167,10 +167,12 @@ Closure commonPackageConfig(String type, boolean oss) {
     configurationFile '/etc/elasticsearch/elasticsearch.yml'
     configurationFile '/etc/elasticsearch/jvm.options'
     configurationFile '/etc/elasticsearch/log4j2.properties'
-    configurationFile '/etc/elasticsearch/role_mapping.yml'
-    configurationFile '/etc/elasticsearch/roles.yml'
-    configurationFile '/etc/elasticsearch/users'
-    configurationFile '/etc/elasticsearch/users_roles'
+    if (oss == false) {
+      configurationFile '/etc/elasticsearch/role_mapping.yml'
+      configurationFile '/etc/elasticsearch/roles.yml'
+      configurationFile '/etc/elasticsearch/users'
+      configurationFile '/etc/elasticsearch/users_roles'
+    }
     into('/etc/elasticsearch') {
       dirMode 0750
       fileMode 0660

docs/java-rest/high-level/supported-apis.asciidoc

@@ -422,7 +422,7 @@ The Java High Level REST Client supports the following Watcher APIs:
 * <<{upid}-start-watch-service>>
 * <<{upid}-stop-watch-service>>
 * <<java-rest-high-x-pack-watcher-put-watch>>
-* <<java-rest-high-x-pack-watcher-get-watch>>
+* <<{upid}-get-watch>>
 * <<java-rest-high-x-pack-watcher-delete-watch>>
 * <<java-rest-high-watcher-deactivate-watch>>
 * <<{upid}-ack-watch>>

docs/reference/query-dsl/query-string-query.asciidoc

@@ -28,14 +28,14 @@ GET /_search
     "query": {
         "query_string" : {
             "default_field" : "content",
-            "query" : "(new york city) OR (big apple)"
+            "query" : "(new york city) OR (big apple)" <1>
         }
     }
 }
 --------------------------------------------------
 // CONSOLE
 
-... will be split into `new york city` and `big apple` and each part is then
+<1> will be split into `new york city` and `big apple` and each part is then
 analyzed independently by the analyzer configured for the field.
 
 WARNING: Whitespaces are not considered operators, this means that `new york city`
@@ -48,7 +48,6 @@ When multiple fields are provided it is also possible to modify how the differen
 field queries are combined inside each textual part using the `type` parameter.
 The possible modes are described <<multi-match-types, here>> and the default is `best_fields`.
 
-
 The `query_string` top level parameters include:
 
 [cols="<,<",options="header",]
@@ -107,8 +106,8 @@ not analyzed. By setting this value to `true`, a best effort will be
 made to analyze those as well.
 
 |`max_determinized_states` |Limit on how many automaton states regexp
-queries are allowed to create.  This protects against too-difficult
-(e.g. exponentially hard) regexps.  Defaults to 10000.
+queries are allowed to create. This protects against too-difficult
+(e.g. exponentially hard) regexps. Defaults to 10000.
 
 |`minimum_should_match` |A value controlling how many "should" clauses
 in the resulting boolean query should match. It can be an absolute value
@@ -154,7 +153,7 @@ fields in the mapping could be expensive.
 ==== Multi Field
 
 The `query_string` query can also run against multiple fields. Fields can be
-provided via the `"fields"` parameter (example below).
+provided via the `fields` parameter (example below).
 
 The idea of running the `query_string` query against multiple fields is to
 expand each query term to an OR clause like this:
@@ -194,7 +193,7 @@ GET /_search
 // CONSOLE
 
 Since several queries are generated from the individual search terms,
-combining them is automatically done using a `dis_max` query with a tie_breaker.
+combining them is automatically done using a `dis_max` query with a `tie_breaker`.
 For example (the `name` is boosted by 5 using `^5` notation):
 
 [source,js]
@@ -289,7 +288,7 @@ GET /_search
 
 The `query_string` query supports multi-terms synonym expansion with the <<analysis-synonym-graph-tokenfilter,
 synonym_graph>> token filter. When this filter is used, the parser creates a phrase query for each multi-terms synonyms.
-For example, the following synonym: `"ny, new york" would produce:`
+For example, the following synonym: `ny, new york` would produce:
 
 `(ny OR ("new york"))`
 
@@ -317,4 +316,121 @@ The example above creates a boolean query:
 that matches documents with the term `ny` or the conjunction `new AND york`.
 By default the parameter `auto_generate_synonyms_phrase_query` is set to `true`.
 
+[float]
+==== Minimum should match
+
+The `query_string` splits the query around each operator to create a boolean
+query for the entire input. You can use `minimum_should_match` to control how
+many "should" clauses in the resulting query should match.
+
+[source,js]
+--------------------------------------------------
+GET /_search
+{
+    "query": {
+        "query_string": {
+            "fields": [
+                "title"
+            ],
+            "query": "this that thus",
+            "minimum_should_match": 2
+        }
+    }
+}
+--------------------------------------------------
+// CONSOLE
+
+The example above creates a boolean query:
+
+`(title:this title:that title:thus)~2`
+
+that matches documents with at least two of the terms `this`, `that` or `thus`
+in the single field `title`.
+
+[float]
+===== Multi Field
+
+[source,js]
+--------------------------------------------------
+GET /_search
+{
+    "query": {
+        "query_string": {
+            "fields": [
+                "title",
+                "content"
+            ],
+            "query": "this that thus",
+            "minimum_should_match": 2
+        }
+    }
+}
+--------------------------------------------------
+// CONSOLE
+
+The example above creates a boolean query:
+
+`((content:this content:that content:thus) | (title:this title:that title:thus))`
+
+that matches documents with the disjunction max over the fields `title` and
+`content`. Here the `minimum_should_match` parameter can't be applied.
+
+[source,js]
+--------------------------------------------------
+GET /_search
+{
+    "query": {
+        "query_string": {
+            "fields": [
+                "title",
+                "content"
+            ],
+            "query": "this OR that OR thus",
+            "minimum_should_match": 2
+        }
+    }
+}
+--------------------------------------------------
+// CONSOLE
+
+Adding explicit operators forces each term to be considered as a separate clause.
+
+The example above creates a boolean query:
+
+`((content:this | title:this) (content:that | title:that) (content:thus | title:thus))~2`
+
+that matches documents with at least two of the three "should" clauses, each of
+them made of the disjunction max over the fields for each term.
+
+[float]
+===== Cross Field
+
+[source,js]
+--------------------------------------------------
+GET /_search
+{
+    "query": {
+        "query_string": {
+            "fields": [
+                "title",
+                "content"
+            ],
+            "query": "this OR that OR thus",
+            "type": "cross_fields",
+            "minimum_should_match": 2
+        }
+    }
+}
+--------------------------------------------------
+// CONSOLE
+
+The `cross_fields` value in the `type` field indicates that fields that have the
+same analyzer should be grouped together when the input is analyzed.
+
+The example above creates a boolean query:
+
+`(blended(terms:[field2:this, field1:this]) blended(terms:[field2:that, field1:that]) blended(terms:[field2:thus, field1:thus]))~2`
+
+that matches documents with at least two of the three per-term blended queries.
+
 include::query-string-syntax.asciidoc[]

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

@@ -37,6 +37,10 @@ of the sort specification. Otherwise the sort order for documents that have
 the same sort values would be undefined and could lead to missing or duplicate
 results. The <<mapping-id-field,`_id` field>> has a unique value per document
 but it is not recommended to use it as a tiebreaker directly.
+Beware that `search_after` looks for the first document which fully or partially
+matches tiebreaker's provided value. Therefore if a document has a tiebreaker value of
+`"654323"` and you `search_after` for `"654"` it would still match that document
+and return results found after it.
 <<doc-values,doc value>> are disabled on this field so sorting on it requires
 to load a lot of data in memory. Instead it is advised to duplicate (client side
  or with a <<ingest-processors,set ingest processor>>) the content

server/src/test/java/org/elasticsearch/search/aggregations/bucket/histogram/InternalDateHistogramTests.java

@@ -71,7 +71,7 @@ public void setUp() throws Exception {
                 //it's ok if min and max are outside the range of the generated buckets, that will just mean that
                 //empty buckets won't be added before the first bucket and/or after the last one
                 long min = baseMillis - intervalMillis * randomNumberOfBuckets();
-                long max = baseMillis + randomNumberOfBuckets() * intervalMillis + randomNumberOfBuckets();
+                long max = baseMillis + randomNumberOfBuckets() * intervalMillis;
                 extendedBounds = new ExtendedBounds(min, max);
             }
             emptyBucketInfo = new InternalDateHistogram.EmptyBucketInfo(rounding, InternalAggregations.EMPTY, extendedBounds);
@@ -86,7 +86,7 @@ protected InternalDateHistogram createTestInstance(String name,
         int nbBuckets = randomNumberOfBuckets();
         List<InternalDateHistogram.Bucket> buckets = new ArrayList<>(nbBuckets);
         //avoid having different random instance start from exactly the same base
-        long startingDate = baseMillis - intervalMillis * randomIntBetween(0, 100);
+        long startingDate = baseMillis - intervalMillis * randomNumberOfBuckets();
         for (int i = 0; i < nbBuckets; i++) {
             //rarely leave some holes to be filled up with empty buckets in case minDocCount is set to 0
             if (frequently()) {

x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/watcher/watch/WatchStatus.java

@@ -234,6 +234,8 @@ public void readFrom(StreamInput in) throws IOException {
         }
         if (in.readBoolean()) {
             headers = in.readMap(StreamInput::readString, StreamInput::readString);
+        } else {
+            headers = Collections.emptyMap();
         }
     }
 

x-pack/plugin/core/src/test/java/org/elasticsearch/protocol/xpack/watcher/GetWatchResponseTests.java

@@ -140,12 +140,10 @@ private static WatchStatus randomWatchStatus() {
             );
             actionMap.put(randomAlphaOfLength(10), actionStatus);
         }
-        Map<String, String> headers = randomBoolean() ? new HashMap<>() : null;
-        if (headers != null) {
-            int headerSize = randomIntBetween(1, 5);
-            for (int i = 0; i < headerSize; i++) {
-                headers.put(randomAlphaOfLengthBetween(5, 10), randomAlphaOfLengthBetween(1, 10));
-            }
+        Map<String, String> headers = new HashMap<>();
+        int headerSize = randomIntBetween(0, 5);
+        for (int i = 0; i < headerSize; i++) {
+            headers.put(randomAlphaOfLengthBetween(5, 10), randomAlphaOfLengthBetween(1, 10));
         }
         return new WatchStatus(version, state, executionState, lastChecked, lastMetCondition, actionMap, headers);
     }