REST : deprecate field_data for Clear Indices Cache API

[olcbean]

Throughout the code and the documentation fielddata is used. Only for the Clear Indices Cache API field_data has been used :

elasticsearch/server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestClearIndicesCacheAction.java

Line 104 in 95a13ea

public static final ParseField FIELD_DATA = new ParseField("field_data", "fielddata");

( if fielddata is used as a url param, a deprecation warning is logged and also returned in the response headers )

Also the reference docs are referring only to fielddata.

For consistency reasons this PR deprecates field_data in favor of fielddata.

---

For context, a few usages of fielddata :

GET /_cat/fielddata

GET /_nodes/stats/indices/fielddata

Index setting : index.fielddata.cache

---

The change from fielddata to field_data has been done in e2c8ff9 ( at this point the two names were interchangeable : no deprecation logging )

Since b927cfe (#17804) a http warning header is sent for the deprecated usage

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[jasontedor]

FYI @elastic/es-core-infra.

[nik9000]

Makes sense to me.

@olcbean, could you add a yaml test for this API that just calls it with the new parameter to make sure the new preferred name? That'd make sure that we parse it and should be quite quick.

I think the right thing to do is, once this is ready, to merge it to master and 6.x and, in a followup, remove the now-deprecated name. @olcbean, would you like to do the follow-up?

@elasticmachine, test this please.

[javanna]

do we want to deprecate in 6.x and remove in 7.0? If so the migrate guide has to be updated.

[olcbean]

Hm...
When a param is removed it should be documented ( in the followup PR )
In some cases when a deprecation is introduced, it is also documented. But I am not sure when.

The question is how to handle the docs ? Should I add a deprecation msg and if so, if I open the PR against master I do not have access to the 6.x migration docs ... I see two possible ways to proceed.

• no deprecation note
• open a separate migration doc PR against 6.x ( once this PR is backported to 6.x )

[olcbean]

@nik9000 @javanna thanks for the reviews!
The PR is ready for another round ;)

[nik9000]

When a param is removed it should be documented ( in the followup PR )

We'll generate a changes list automatically. The script should pick up anything with breaking and deprecation labels and group them into the right section.

[nik9000]

@elasticmachine, test this please

[nik9000]

It looks like the PR test failures are because this needs to be simultaneously backported. That is no problem. I'll test locally.

[spinscale]

I have pushed 9f2c4df to fix failing tests until the backport is done.

[nik9000]

I have pushed 9f2c4df to fix failing tests until the backport is done.

I pushed the backport and reverted this. Sorry for the noise.