This commit removes FilterBytesValues which is very trappy as the default
implementation forwards all method calls to the delegate. So if you do any
non-trivial modification to the terms or to the order of the terms, you need
to remember to override currentValueHash, copyShared, and this is very
error-prone.
FieldDataSource.WithScript.BytesValues and ScriptBytesValues now return correct
hash codes, future bugs here would be catched by the new assertion in
SortedUniqueBytesValues.
This bug was causing performance issues with scripts as all terms were assumed
to have the same hash code.
Close#5004
* Mostly minor things like typos and grammar stuff
* Some clarifications
* The note on the deprecation was ambiguous. I've removed the problematic part so that it now definitely says it's deprecated
The last response body gets now always stashed in the REST tests and can be retrieved via `$body`. This implies that not only expected values can be retrieved from the stashed values, but actual values as well.
Added support for regular expressions to `match` assertion, using `Pattern.COMMENTS` flag for better readability through new custom hamcrest matcher (adopted in do section as well). Functionality added through new feature called `regex` that needs to be mentioned in the skip sections whenever needed till all the runners support it.
Added also example tests for cat count api
Our yaml parser seems to be too tolerant in some cases, e.g. it properly parses yaml suites when they don't end with a line feed, whereas other clients tests break due to that. We should try to do the same to keep consistency across runners.
Upgrading 0.90.x `multi_field` type that has a `geo_point` or `completion` field type as default field would otherwise fail.
Also it make sense to support these field types, because both support specifying the actual values as string.
Currently, boosting on `copy_to` is misleading and does not work as originally specified in #4520. Instead of boosting just the terms from the origin field, it boosts the whole destination field. If two fields copy_to a third field, one with a boost of 2 and another with a boost of 3, all the terms in the third field end up with a boost of 6. This was not the intention.
The alternative: to store the boost in a payload for every term, results in poor performance and inflexibility. Instead, users should either (1) query the common field AND the field that requires boosting, or (2) the multi_match query will soon be able to perform term-centric cross-field matching that will allow per-field boosting at query time (coming in 1.1).
As we have different runners for the REST tests we need a mechanism that allows us to add features to any of them without breaking all others builds.
The idea is to name a feature and temporarily use skip sections that mention the required new features, so that runners that don't support it will skip the test.
Added support for `features` field in skip section.
Added `Features` class that contains a static list of the features supported by the runner. If a feature mentioned in a skip section is not listed here, the test will be skipped.
When fixing #4738, a small issue leaked into the implementation.
The equals check in the RestAction only applied when the master node
returned the rest request, otherwise the object equality would not hold
due to being transferred over the wire and being deserialized into
another object (from and an equality point of view) than the
FieldMappingMetaData.NULL object - this could result in serialization
exceptions as an empty length bytes reference is used in toXContent.
By default active, rejected and queue thread statistics are included for the index, bulk and search thread pool.
Other thread statistics of other thread pools can be included via the `h` query string parameter.
Closes#4907
In recent changes, we added missing support for `source` parameter in some REST APIs:
* #4892 : mget
* #4900 : mpercolate
* #4901 : msearch
* #4902 : mtermvectors
* #4903 : percolate
```java
BytesReference content = null;
if (request.hasContent()) {
content = request.content();
} else {
String source = request.param("source");
if (source != null) {
content = new BytesArray(source);
}
}
```
It's definitely better to have:
```java
BytesReference content = request.content();
if (!request.hasContent()) {
String source = request.param("source");
if (source != null) {
content = new BytesArray(source);
}
}
```
That said, it could be nice to have a single method to manage it for various REST actions.
Closes#4924.
Adrien Grand
Luca Cavanna
Clinton Gormley
Jun Ohtani
Lars Francke
Simon Willnauer
Shay Banon
markharwood
George P. Stathis
Martijn van Groningen
Igor Motov
Lee Hinman
Mark Conlin
David Pilato
Alexander Reelsen
uboness
mrsolo