Implement auto-upgrade mechanism for joda-java migration

[pgomulka]

it requires at the moment a new mapping creation and a reindex in order to fix date formats. This is a bit tedious for users, especially when their formats were compatible like
YYYY-MM-dd => yyyy-mm-dd
We should implement a mechanism that will automatically upgrade the mapping for users in situations like this. If it won't be able to confirm 100% that the mapping can be autoupgraded, it should not do any action and user would be forced to create new mapping/reindex (as he has to now)
We could consider to allow mapping modifications for these fields. Or use a reindex with alias to allow smooth migration (and still allowing to index documents)

[elasticmachine]

Pinging @elastic/es-core-infra

[pgomulka]

I wonder to what degree this should be automatic. It might be easy to implement a simple regexp where yyyy is replaced with uuuu (assuming no custom text (') was used in a pattern)
but allowing more complex patterns might end up fairly complex

[pgomulka]

Similar logic that allows reindex exists at the moment in kibana but there is plan to migrate some of this to ES plugin.
Maybe we could implement a mechanism that would make it easier to perform such migrations in the future?
elastic/kibana#49764

[rjernst]

I wonder to what degree this should be automatic

I don't think we can do this automatically since we can't distinguish when they actually wanted yyyy?

[pgomulka]

I thought this change would go to 6.8 where the context of pattern without of an 8 prefix should be clear
so if they had YYYY then after autoupgrade they would have 8yyyy

[richiejarvis]

I wonder to what degree this should be automatic

I don't think we can do this automatically since we can't distinguish when they actually wanted yyyy?

I think it is safe to assume that if the format yyyy was used successfully under joda time, then it should be auto translated to the equivilent in the new library. That will give consistent behaviour with how the format worked before.

In other words, if it was wrong previously, it will be wrong after the change as well, but in a consistent manner.

Cheers,

Richie

[williamrandolph]

@pgomulka Is this work still planned? Since we are now developing 7.x and 8.x, I am not sure if an upgrade mechanism for 6.8.x will be useful.

[rjernst]

Given that we haven't had anymore requests for this in many years, and we are fully using Java time formats, I'm going to close this issue.