New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for backwards compatibility for unix timestamp in pre 2.x indices #11515
Allow for backwards compatibility for unix timestamp in pre 2.x indices #11515
Conversation
@@ -557,13 +559,22 @@ public boolean autoGeneratedId() { | |||
return this.autoGeneratedId; | |||
} | |||
|
|||
private static Version getIndexVersionFromIndex(String index, MetaData metaData) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use Version.indexeCreated
? How is it possible to be looking up created version for an index that doesn't exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@spinscale Thanks for adding this bwc. I left a couple comments. |
After a discussion with Boaz, we should add a configurable mapping option, that supports parsing a unix timestamp by default, but can be disabled via the mapping in order to not break existing applications |
@spinscale @bleskes Can you elaborate on why we need an option? We've been making lots of efforts to reduce options on mappings so adding a new one feels a bit like going backwards? |
@jpountz it is my understanding the idea is not to introduced another param but rather change the default date parsing such that it does what the old code used to do (give preference to unix time stamps) but this time all the parsing goes through the proper channels (field mappers), making it simpler and allowing people which don't like it the ability to change it. |
If we only change the default behaviour based on when the index was created then I'm good. |
@jpountz we do it all the time as we used to di this hard coded in code. Now it will be configurable (and the same by default) |
@spinscale any idea when you can work on this / get this in? |
ec77f90
to
8898f41
Compare
rebased against master and fixed some tests, need to add more tests to ensure expected behaviour |
8898f41
to
11ceb48
Compare
*/ | ||
public class DateBackwardsCompatibilityTests extends ElasticsearchSingleNodeTest { | ||
|
||
long dateInMillis = 1435073872l * 1000; // Tue Jun 23 17:37:52 CEST 2015 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why isn't this a local var in the couple tests that use it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@@ -289,7 +288,7 @@ public void testIgnoreMalformedOption() throws Exception { | |||
.endObject() | |||
.bytes()); | |||
} catch (MapperParsingException e) { | |||
assertThat(e.getCause(), instanceOf(MapperParsingException.class)); | |||
assertThat(e.getCause(), instanceOf(IllegalArgumentException.class)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we check part of the message so we know we got the right exception? ditto for the other cases like this in this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed for all the cases, checking content of e.getMessage()
now
@spinscale I left some more comments. |
11ceb48
to
7d53a06
Compare
worked on all your review comments, except the documentation one, which I think should be kept there to not confuse users trying to look |
7d53a06
to
81a5beb
Compare
LGTM, thanks! I left one small comment on the wording for migration docs. |
In order to be backwards compatible, indices created before 2.x must support indexing of a unix timestamp and its configured date format. Indices created with 2.x must configure the `epoch_millis` date formatter in order to support this. Relates elastic#10971
81a5beb
to
23cf9af
Compare
In order to be backwards compatible, indices created before 2.x must support
indexing of a unix timestamp and its configured date format. Indices created
with 2.x must configure the
epoch_millis
date formatter in order tosupport this. Also the
numeric_resolution
parameter is not needed anymore,as this is configured by either using
epoch_millis
orepoch_seconds
, howeverit must still be supported for older indices.
Relates #10971