Query Changes

• Changes to Encoding Plus Signs in URLs (7.4)

  • Starting in version 7.4, a + in a URL will be encoded as %2B by all REST API functionality. Prior versions handled a + as a single space. If your application requires handling + as a single space

  • this may affect any Lucene queries used in our system

• Aggregating and sorting on _id is deprecated (7.6)

  • It’s possible to aggregate and sort on the built-in _id field by loading an expensive data structure called fielddata. This was deprecated in 7.6 and will be disallowed by default in 8.0

• Geo-Shape queries/mapping (7.7+)

  • According to the 7.9 docs on geo-shape queries:

    • Requires the geo_shape Mapping or the geo_point Mapping.

  • I don't think it'll apply to our mapping because we use geo-shape mapping type, which supports GEOJson (Multi)Point types (which we support now)
  • Handle properly indexing rectangles that crosses the dateline #53810

Mapping Changes

• Validation for dynamic templates (7.7)
  

  • So far misconfiguration of dynamic templates have been discovered when indexing a document with an unmapped field only. In Elasticsearch 8.0 and later versions, dynamic mappings have stricter validation, done at mapping update time. Invalid updates, such as using incorrect analyzer settings or unknown field types, fail. For indices created in Elasticsearch 7.7 and later version, the update succeeds but emits a warning.

  • This may affect the mapping in grq and mozart's ElasticSearch

Logging Changes

• Loggers under org.elasticsearch.action now log at INFO level by default (7.7)
  

  • The default log level for most loggers is INFO, but in earlier versions loggers in the org.elasticsearch.action.* hierarchy emitted log messages at DEBUG level by default. This sometimes resulted in a good deal of unnecessary log noise. From 7.7 onwards the default log level for logger in this hierarchy is now INFO

Kibana Changes

• The kibana user has been deprecated in favor of the kibana_system user (7.8)

  • The kibana user was historically used to authenticate Kibana to Elasticsearch. The name of this user was confusing, and was often mistakenly used to login to Kibana. We’ve replaced the kibana user with the kibana_system user to reduce confusion and to better align with other built-in system accounts

• Changes to built-in roles (7.8)
  

  • Users who were previously assigned the kibana_user role should instead be assigned the kibana_admin role. This role grants the same set of privileges as kibana_user, but has been renamed to better reflect its intended use

  • Assign users with the kibana_user role to the kibana_admin role. Discontinue use of the kibana_user role.