Elasticsearch: Field names cannot contain the . character in Elasticsearch 2.0

Created on 7 Nov 2015 · 6Comments · Source: elastic/elasticsearch

Starting with Elasticsearch 2.0 field names can not contain the . character anymore.

I like to use . as separator in field names while using _ instead of camel casing - i.e. docker.label.some_stuff instead of docker_label_some_stuff since it makes the parsing much easier.

Any chance field names with a . will be allowed in Elasticsearch 2.x?

Source

digital-wonderland

Most helpful comment

Dots in field names are allowed in ES 2.4 and 5.0, this is an older issues. See: https://github.com/elastic/elasticsearch/pull/19937

dakrone on 27 Oct 2016

🎉3

All 6 comments

No. Dots are used in paths all over the place, to represent keys in an object. The fewer decision trees there are in the code, the less likely we're going to forget to implement something in a new area of code.

You could use dashes or slashes or a number of other characters instead.

clintongormley on 8 Nov 2015

We have an existing index which is created using Elasticsearch 1.0.2. We are planning to upgrade to 2.3.3. Also we have some fields which have dots in the filed names. Can we use de-dot filter to convert the dots to another character in the existing index? ie.. we don't want to delete the index and create new index with the updated mappings. or does de-dot filter work only for the new fields added?

Yasaswani on 16 Jun 2016

@Yasaswani you can't unfortunately. reindexing is the only way forward

clintongormley on 16 Jun 2016

I just ran into this issue when upgrading to 2.3. While it wouldn't be too hard to switch the dots to dashes or slashes, it goes against a lot of standards already in place. For example, one of my plugins is collecting data from docker, who's standard is dots as separators. ECS actually takes this one step further and enforces that standard. The are also many others that use the same standard (DNS and Java, just to name a few).

By not allowing dots, I am now going to have to keep converting back and forth which is not only annoying but also a source of confusion and possible bugs in the future.

nickwilmes on 27 Oct 2016

+1 for consistency with java and Docker Metadata; https://docs.docker.com/engine/userguide/labels-custom-metadata/ describes how metadata should be namespaced similiar to Java using periods. This is prime data to be loaded into ElasticSearch via LogStash, and prohibiting periods adds needless conversions to the input data (and breaks the upgrade path).