root
/
elasticsearch
mirror of https://github.com/elastic/elasticsearch.git
1
0
Fork 0
Code Issues Actions 1 Packages Projects Releases Wiki Activity
elasticsearch/docs/reference/migration/migrate_8_0.asciidoc

50 lines
1.5 KiB
Plaintext
Raw Normal View History

[DOCS] Adds placeholders for v8 highlights, breaking changes, release notes (#38641)
2019-02-09 07:48:42 +08:00
[[breaking-changes-8.0]]
== Breaking changes in 8.0
++++
<titleabbrev>8.0</titleabbrev>
++++
This section discusses the changes that you need to be aware of when migrating
your application to {es} 8.0.
See also <<release-highlights>> and <<es-release-notes>>.
Remove `nGram` and `edgeNGram` token filter names (#38911) In #30209 we deprecated the camel case `nGram` filter name in favour of `ngram` and did the same for `edgeNGram` and `edge_ngram`. Using these names has been deprecated since 6.4 and is issuing deprecation warnings since then. I think we can remove these filters in 8.0. In a backport of this PR I would change what was a dreprecation warning from 6.4. to an error starting with new indices created in 7.0.
2019-02-16 03:15:05 +08:00
coming[8.0.0]
Move some token filter migration notes (#39072) The removal of the "nGram" and "edgeNGram" token filter was filed in a new migrate_8_0/mappings.asciidoc document but it should better be in an analysis.asciidoc section and file.
2019-02-26 22:02:43 +08:00
* <<breaking_80_analysis_changes>>
Remove Zen1 (#39466) Removes all traces of Zen1 from the code base. Some of these commits will also be backported to 7.0/7.x (#39470) as the cluster.coordination package was making use of some things in discovery.zen and we want to keep 7.x as close as possible to master.
2019-03-04 22:51:12 +08:00
* <<breaking_80_discovery_changes>>
Remove `nGram` and `edgeNGram` token filter names (#38911) In #30209 we deprecated the camel case `nGram` filter name in favour of `ngram` and did the same for `edgeNGram` and `edge_ngram`. Using these names has been deprecated since 6.4 and is issuing deprecation warnings since then. I think we can remove these filters in 8.0. In a backport of this PR I would change what was a dreprecation warning from 6.4. to an error starting with new indices created in 7.0.
2019-02-16 03:15:05 +08:00
* <<breaking_80_mappings_changes>>
Bump the minimum Java version to Java 11 (#40754) With the 8.0.0 release of Elasticsearch we will bump the minimum required Java to Java 11. This commit puts this into effect on the master branch.
2019-04-08 04:16:23 +08:00
* <<breaking_80_packaging_changes>>
Unify blob store compress setting (#39346) Blob store compression was all implemented generally, except reading the setting for it. Moved the setting to BlobStoreRepository to unify this. Also removed deprecated env setting 'repositories.fs.compress'. This is a follow up on #39073
2019-02-28 19:34:13 +08:00
* <<breaking_80_snapshots_changes>>
Remove obsolete security settings (#40496) Removes the deprecated accept_default_password setting. This setting become redundant when default passwords were removed from 6.0, but the setting was kept for BWC. Removes native role store cache settings. These have been unused since 5.2 but were kept for BWC.
2019-03-29 15:04:49 +08:00
* <<breaking_80_security_changes>>
Make Fuzziness reject illegal values earlier (#33511) The current java implementation of Fuzziness leaves a lot of room for initializing it with illegal values that either cause errors later when the queries reach the shards where they are executed or values that are silently ignored in favour of defaults. We should instead tighten the java implementation of the class so that we only accept supported values. Currently those are numeric values representing the edit distances 0, 1 and 2, optionally also as float or string, and the "AUTO" fuzziness, which can come in a cusomizable variant that allows specifying two value that define the positions in a term where the AUTO option increases the allowed edit distance. This change removes several redundant ways of object construction and adds input validation to the remaining ones. Java users should either use one of the predefined constants or use the static factory methods `fromEdits(int)` or `fromString(String)` to create instances of the class, while other ctors are hidden. This allows for instance control, e.g. returning one of the constants when creating instances from an integer value. Previously the class would accept any positive integer value and any float value, while in effect the maximum allowed edit distance was capped at 2 in practice. These values while throw an error now, as will any other String value other than "AUTO" that where previously accepted but led to numeric exceptions when the query was executed.
2019-04-05 16:35:35 +08:00
* <<breaking_80_java_changes>>
Remove `nGram` and `edgeNGram` token filter names (#38911) In #30209 we deprecated the camel case `nGram` filter name in favour of `ngram` and did the same for `edgeNGram` and `edge_ngram`. Using these names has been deprecated since 6.4 and is issuing deprecation warnings since then. I think we can remove these filters in 8.0. In a backport of this PR I would change what was a dreprecation warning from 6.4. to an error starting with new indices created in 7.0.
2019-02-16 03:15:05 +08:00
[DOCS] Removes notable breaking changes section
2019-03-23 06:45:13 +08:00
//NOTE: The notable-breaking-changes tagged regions are re-used in the
//Installation and Upgrade Guide
[DOCS] Adds notable changes section (#38238)
2019-03-09 02:51:27 +08:00
//tag::notable-breaking-changes[]
[float]
==== Indices created before 7.0
Enforce Completion Context Limit (#38675) This change adds a limit to the number of completion contexts that a completion field can define. Closes #32741
2019-02-18 19:51:40 +08:00
Elasticsearch 8.0 can read indices created in version 7.0 or above. An
Elasticsearch 8.0 node will not start in the presence of indices created in a
version of Elasticsearch before 7.0.
[IMPORTANT]
.Reindex indices from Elasticsearch 6.x or before
=========================================
Indices created in Elasticsearch 6.x or before will need to be reindexed with
Elasticsearch 7.x in order to be readable by Elasticsearch 8.x.
=========================================
[DOCS] Adds notable changes section (#38238)
2019-03-09 02:51:27 +08:00
// end::notable-breaking-changes[]
Enforce Completion Context Limit (#38675) This change adds a limit to the number of completion contexts that a completion field can define. Closes #32741
2019-02-18 19:51:40 +08:00
Move some token filter migration notes (#39072) The removal of the "nGram" and "edgeNGram" token filter was filed in a new migrate_8_0/mappings.asciidoc document but it should better be in an analysis.asciidoc section and file.
2019-02-26 22:02:43 +08:00
include::migrate_8_0/analysis.asciidoc[]
Remove Zen1 (#39466) Removes all traces of Zen1 from the code base. Some of these commits will also be backported to 7.0/7.x (#39470) as the cluster.coordination package was making use of some things in discovery.zen and we want to keep 7.x as close as possible to master.
2019-03-04 22:51:12 +08:00
include::migrate_8_0/discovery.asciidoc[]
Move some token filter migration notes (#39072) The removal of the "nGram" and "edgeNGram" token filter was filed in a new migrate_8_0/mappings.asciidoc document but it should better be in an analysis.asciidoc section and file.
2019-02-26 22:02:43 +08:00
include::migrate_8_0/mappings.asciidoc[]
Bump the minimum Java version to Java 11 (#40754) With the 8.0.0 release of Elasticsearch we will bump the minimum required Java to Java 11. This commit puts this into effect on the master branch.
2019-04-08 04:16:23 +08:00
include::migrate_8_0/packaging.asciidoc[]
Unify blob store compress setting (#39346) Blob store compression was all implemented generally, except reading the setting for it. Moved the setting to BlobStoreRepository to unify this. Also removed deprecated env setting 'repositories.fs.compress'. This is a follow up on #39073
2019-02-28 19:34:13 +08:00
include::migrate_8_0/snapshots.asciidoc[]
Remove obsolete security settings (#40496) Removes the deprecated accept_default_password setting. This setting become redundant when default passwords were removed from 6.0, but the setting was kept for BWC. Removes native role store cache settings. These have been unused since 5.2 but were kept for BWC.
2019-03-29 15:04:49 +08:00
include::migrate_8_0/security.asciidoc[]
Make Fuzziness reject illegal values earlier (#33511) The current java implementation of Fuzziness leaves a lot of room for initializing it with illegal values that either cause errors later when the queries reach the shards where they are executed or values that are silently ignored in favour of defaults. We should instead tighten the java implementation of the class so that we only accept supported values. Currently those are numeric values representing the edit distances 0, 1 and 2, optionally also as float or string, and the "AUTO" fuzziness, which can come in a cusomizable variant that allows specifying two value that define the positions in a term where the AUTO option increases the allowed edit distance. This change removes several redundant ways of object construction and adds input validation to the remaining ones. Java users should either use one of the predefined constants or use the static factory methods `fromEdits(int)` or `fromString(String)` to create instances of the class, while other ctors are hidden. This allows for instance control, e.g. returning one of the constants when creating instances from an integer value. Previously the class would accept any positive integer value and any float value, while in effect the maximum allowed edit distance was capped at 2 in practice. These values while throw an error now, as will any other String value other than "AUTO" that where previously accepted but led to numeric exceptions when the query was executed.
2019-04-05 16:35:35 +08:00
include::migrate_8_0/java.asciidoc[]