Emit deprecation warning when TermsLookup contains a type #53731
Conversation
romseygeek
added
:Search/Search
|
Pinging @elastic/es-search (:Search/Search) |
|
This also refactors TermsLookup to use an ObjectParser. I'll open a separate PR against master to forward port this part. |
This commit refactors the fromXContent method in TermsLookup to use an ObjectParser and adds an explicit parsing test. Related to #53731
There was a problem hiding this comment.
Thanks @romseygeek, this looks very good for me.
We also need to adjust documentation that id, path and routing are required fields in terms lookup. Or may the documentation meant that the whole terms lookup is optional, in this case we don't need to change anything there.
|
@elasticsearchmachine test this please |
| .boost(boost) | ||
| .queryName(queryName); | ||
|
|
||
| if (builder.isTypeless() == false) { |
There was a problem hiding this comment.
@romseygeek sorry for the late review, I'm wondering why this check wasn't sufficient for emitting a deprecation warning? Was it not triggered on all the relevant code paths?
It would be nice to keep this strategy if possible, since it's consistent with all our other types deprecation warnings (deprecatedAndMaybeLog("api_name_with_types", TYPES_DEPRECATION_MESSAGE);). It also lets us avoid adding an allowed_warnings section to the yml tests, since in 7.x we already ignore all warnings in yml tests that start with [types removal] ... .
There was a problem hiding this comment.
There was a path that didn't trigger the warning, but I can't find it now, so it may have been refactored away elsewhere. I'll have a look, it would be good to remove some of these extra allowed_warnings messages.
TermsLookupin master no longer accepts atypeparameter. We should emita deprecate warning in 7.x when a terms lookup requests includes
typeto prepareusers for its removal.
Relates to #41059