Also replaced int,String pair with ShardId that holds the same info and serializes it the same way.
Replaced shardId and index getters in BroadcastOperationRequest with a single ShardId getter.
Closes#7255
The geohash grid it 8 cells wide and 4 cells tall. GeoHashUtils.neighbor(String,int,int.int) set the limit of the number of cells in y to < 3 rather than <= 3 resulting in it either not finding all neighbours or incorrectly searching for a neighbour in a different parent cell.
Closes#7226
This change stores the index creation time in the index metadata when an index is created. The creation time cannot be changed but can be set as part of the create index request to allow for correct creation times for historical data.
Closes#7119
In order to have the possibility of debugging on the command line, the user
now can either set the es.cli.debug system property
which results in stack traces being written to to the terminal.
Closes#7222
A range filter on a date field with a numeric `from`/`to` value is **not** cached by default:
DELETE /test
PUT /test/t/1
{
"date": "2014-01-01"
}
GET /_validate/query?explain
{
"query": {
"filtered": {
"filter": {
"range": {
"date": {
"from": 0
}
}
}
}
}
}
Returns:
"explanation": "ConstantScore(no_cache(date:[0 TO *]))"
This patch fixes as well not caching `from`/`to` when using `now` value not rounded.
Previously, a query like:
GET /_validate/query?explain
{
"query": {
"filtered": {
"filter": {
"range": {
"date": {
"from": "now"
"to": "now/d+1"
}
}
}
}
}
}
was cached.
Also, this patch does not cache anymore `now` even if the user asked for caching it.
As it won't be cached at all by definition.
Added as well tests for all possible combinations.
Closes#7114.
When installing a bin only plugin, it is identified as a site plugin.
A current workaround would be to create in the zip file another empty dir. So if you have:
* `bin/myfile.sh`
* `empty/empty.txt`
the `bin` content will be extracted as expected.
Closes#7152.
indexRandom will try to delete bogus documents multiple times since they get tracked by indexOrAlias/id, and after the actual deletion any other attempt throws error and fails the test
An anti-pattern that we have in our code, noticeable for java API users, is that we modify incoming requests by replacing the index or alias with the concrete index. This way not only the request has changed, but all following communications that use that request will lose the information on whether the original request was performed against an alias or an index.
Refactored the following base classes: `TransportShardReplicationOperationAction`, `TransportShardSingleOperationAction`, `TransportSingleCustomOperationAction`, `TransportInstanceSingleOperationAction` and all subclasses by introduced an InternalRequest object that contains the original request plus additional info (e.g. the concrete index). This internal request doesn't get sent over the transport but rebuilt on each node on demand (not different to what currently happens anyway, as concrete index gets set on each node). When the request becomes a shard level request, instead of using the only int shardId we serialize the ShardId that contains both concrete index name (which might then differ ffrom the original one within the request) and shard id.
Using this pattern we can move get, multi_get, explain, analyze, term_vector, multi_term_vector, index, delete, update, bulk to not replace the index name with the concrete one within the request. The index name within the original request will stay the same.
Made it also clearer within the different transport actions when the index needs to be resolved and when that's not needed (e.g. shard level request), by exposing `resolveIndex` method. Moved check block methods to parent classes as their content was always the same on every subclass.
Improved existing tests by randomly introducing the use of an alias, and verifying that the responses always contain the concrete index name and not the original one, as that's the expected behaviour.
Added backwards compatibility tests to make sure that the change is applied in a backwards compatible manner.
Closes#7223
If a geo_shape had edges which either ran vertically along the dateline or touched the date line but did not cross it they would fail to parse. This is because the code which splits a polygon along the dateline did not take into account the case where the polygon touched but did not cross the dateline. This PR fixes those issues and provides tests for them.
Close#7016
The `.percolator` type is a hidden type and therefor the types from the delete mapping request should passed down to the delete by query request, otherwise the percolator type gets ignored and the percolator queries don't get deleted from disk (only unregistered).
Closes#7087
internal cluster communication.
See CorruptedCompressorTests for details on how this bug can be hit.
This change also removes the ability to use the unsafe variant of
ChunkedEncoder, removing support for the compress.lzf.decoder setting.
If a dynamic mapping for a geo_point field is defined and the first document specifies the value of the field as a geo_point array, the dynamic mapping throws an error as the array is broken into individual number before consulting the dynamic mapping configuration. This change adds a check of the dynamic mapping before the array is split into individual numbers.
Closes#6939
This test assumed that the `num` field was mapped as an integer on all shards
and thus that all of them should fail when providing a timezone. However, since
it used dynamic mappings, some shards might have this field not mapped, as a
consequence they didn't fail.
TransportSingleCustomOperationAction is subclassed by two similar, yet different transport action: TransportAnalyzeAction and TransportGetFieldMappingsAction. Made their difference and similarities more explicit by sharing common code and moving specific code to subclasses:
- moved index field to the parent SingleCustomOperationAction class
- moved the common check blocks code to the parent transport action class
- moved the main transport handler to the TransportAnalyzeAction subclass as it is only used to receive external requests through clients. In the case of the TransportGetFieldMappingsIndexAction instead, the action is internal and executed only locally as part of the user facing TransportGetFieldMappingsAction. The corresponding request gets sent over the transport though as part of the related shard request
- removed the get field mappings index action from the action names mapping as it is not a transport handler anymore. It was before although never used.
Closes#7214
TransportIndexReplicationAction is always executed locally, as an internal action that is part of either delete by query or delete (when routing is required but not specified). Only the corresponding shard level requests get sent over the transport, hence no transport endpoint is needed for the index version, nor the index request itself is supposed to be sent over the transport.
Moved classes from org.elasticsearch.action.delete.index to org.elasticsearch.action.delete and adjusted visibility so that internal requests are not public anymore.
Also removed serialization code from IndexDeleteResponse as it never gets sent over transport either.
Closes#7211
javanna
uboness
Colin Goodheart-Smithe
Alexander Reelsen
Areek Zillur
Ryan Ernst
Lee Hinman
Thomas Peuss
David Pilato
mikemccand
Martijn van Groningen
Adrien Grand
olivier bourgain
Robert Muir
Clinton Gormley