[[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 <> 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 <> or <> 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 <> can include <> which are automatically applied to any search performed via the alias. <> 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 <> or <> apis. ==== Indices APIs The <> 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 <> 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' -------------------------------------------------- The <> 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: <>