The _timestamp field will only accept the enabled, format, and default parameters in future indices. Importantly, it will not be possible to extract the _timestamp value from a path., in type: record.
I'm using this mapping : "_timestamp": { "enabled": true, "store": true, "doc_values": true }
To be able to access the _timestamp value. Does it mean that in 2.0 the "store" feature won't be possible?
This refers to a few things. They both stem from this, but to give a little color, I'll go in opposite order of what the warning is given
First, the "it will not be possible to extract the _timestamp value from a path" refers to the deprecation/discussion here. It's a fairly short and easy read, so you may want to have a look over that to see if there's anything that affects you.
Second, the "the _timestamp field will only accept the enabled, format, and default parameters in future indices" relates to locking down bizarre (and sometimes ambiguous) mappings. On the contrary to it not being stored, the option to not store it was removed, so any explicit store setting is warned against. That part comes from this. There are a number of weird combinations which were removed.
All of this said, you probably shouldn't be using the _timestamp if you can avoid it. Instead, you can use a regular date field, which allows you to use multiple dates/times in the same document, etc.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.