In 0.90.x I was able to delete all my indices from the java api by calling
client.admin().indices().prepareDelete(new String[] {}).execute().actionGet();
However this fails in 1.0.0 with
org.elasticsearch.action.ActionRequestValidationException: Validation Failed: 1: index / indices is missing;
at org.elasticsearch.action.ValidateActions.addValidationError(ValidateActions.java:29)
at org.elasticsearch.action.admin.indices.delete.DeleteIndexRequest.validate(DeleteIndexRequest.java:72)
*snip long stacktrace*
which points me to
public ActionRequestValidationException validate() {
ActionRequestValidationException validationException = null;
if (indices == null || indices.length == 0) {
validationException = addValidationError("index / indices is missing", validationException);
}
return validationException;
}
So that's what now throws the error, however the documentation still says:
/**
* Deletes an index based on the index name.
*
* @param indices The indices to delete. Empty array to delete all indices.
*/
DeleteIndexRequestBuilder prepareDelete(String... indices);
Closes#5164.
Closes#5167.
Closes#5168.
The old post installation script on debian set all data to
644 inside of /etc/elasticsearch, which does not work, when
there are subdirectories
Closes#3820
It is now possible to specify aliases during index creation:
curl -XPUT 'http://localhost:9200/test' -d '
{
"aliases" : {
"alias1" : {},
"alias2" : {
"filter" : { "term" : {"field":"value"}}
}
}
}'
Closes#4920
Nodes that receive the cluster state, and they have several of those pending, can optimize and try and process potentially only one of those.
closes#5139
more assertAcked, checked that the `discovery.zen.publish_timeout` has been changed in `DiscoverySettings`, removed restriction on number of nodes, doesn't seem needed.
`custom_boost_factor` and `custom_score` were deprecated in `0.90.5`
and their documentation was removed already in `1.0`. This commit
removes all support for those queries since they are supercede by
`function_score`.
`discovery.zen.publish_timeout` controls how long the master node is going to try and wait for all the nodes to respond to a cluster state publish before going ahead with the following updates in the queue (default 30s). Up until now changing the settings required restarting each node. The setting is now dynamic and can be changed through the cluster update settings api.
Closes#5063
In order to be consistent (and because in 1.0 we switched from
parameter driven information to specifzing the metrics as part of the URI)
this patch moves from 'plugin' to 'plugins' in the Nodes Info API.
AndDocIdSet#IteratorBasedIterator was potentially initialized with
NO_MORE_DOCS which violates the initial state of DocIdSetIterator and
could lead to undefined behavior when used in a search context.
Closes#5049