82 lines
3.2 KiB
Plaintext
82 lines
3.2 KiB
Plaintext
[[breaking-changes-1.x]]
|
|
== Breaking changes in 1.x
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
your application from Elasticsearch 1.x to Elasticsearch 1.y.
|
|
|
|
[float]
|
|
=== Facets
|
|
|
|
Facets are deprecated and will be removed in a future release. You are
|
|
encouraged to migrate to <<search-aggregations, aggregations>> instead.
|
|
|
|
[[breaking-changes-1.4]]
|
|
=== 1.4
|
|
|
|
==== Percolator
|
|
|
|
In indices created with version `1.4.0` or later, percolation queries can only
|
|
refer to fields that already exist in the mappings in that index. There are
|
|
two ways to make sure that a field mapping exist:
|
|
|
|
* Add or update a mapping via the <<indices-create-index,create index>> or
|
|
<<indices-put-mapping,put mapping>> apis.
|
|
* Percolate a document before registering a query. Percolating a document can
|
|
add field mappings dynamically, in the same way as happens when indexing a
|
|
document.
|
|
|
|
==== Aliases
|
|
|
|
<<indices-aliases,Aliases>> can include <<query-dsl-filters,filters>> which
|
|
are automatically applied to any search performed via the alias.
|
|
<<filtered,Filtered aliases>> created with version `1.4.0` or later can only
|
|
refer to field names which exist in the mappings of the index (or indices)
|
|
pointed to by the alias.
|
|
|
|
Add or update a mapping via the <<indices-create-index,create index>> or
|
|
<<indices-put-mapping,put mapping>> apis.
|
|
|
|
==== Indices APIs
|
|
|
|
The <<warmer-retrieving, get warmer api>> will return a section for `warmers` even if there are
|
|
no warmers. This ensures that the following two examples are equivalent:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
curl -XGET 'http://localhost:9200/_all/_warmers'
|
|
|
|
curl -XGET 'http://localhost:9200/_warmers'
|
|
--------------------------------------------------
|
|
|
|
The <<alias-retrieving, get alias api>> will return a section for `aliases` even if there are
|
|
no aliases. This ensures that the following two examples are equivalent:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
curl -XGET 'http://localhost:9200/_all/_aliases'
|
|
|
|
curl -XGET 'http://localhost:9200/_aliases'
|
|
--------------------------------------------------
|
|
|
|
In addition, the <<alias-retrieving, get alias api>> now supports <<multi-index>> options and, by default, will
|
|
produce an error response if a requested index does not exist.
|
|
|
|
The <<indices-get-mapping, get mapping api>> will return a section for `mappings` even if there are
|
|
no mappings. This ensures that the following two examples are equivalent:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
curl -XGET 'http://localhost:9200/_all/_mappings'
|
|
|
|
curl -XGET 'http://localhost:9200/_mappings'
|
|
--------------------------------------------------
|
|
|
|
==== Zen discovery
|
|
|
|
Each cluster must have an elected master node in order to be fully operational. Once a node loses its elected master
|
|
node it will reject some or all operations.
|
|
|
|
On versions before `1.4.0.Beta1` all operations are rejected when a node loses its elected master. From `1.4.0.Beta1`
|
|
only write operations will be rejected by default. Read operations will still be served based on the information available
|
|
to the node, which may result in being partial and possibly also stale. If the default is undesired then the
|
|
pre `1.4.0.Beta1` behaviour can be enabled, see: <<modules-discovery-zen,no-master-block>> |