-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Disallow disabling _field_names
#27239
Comments
Caveat to this: |
@elastic/es-search-aggs |
As part of this ticket, can we also clarify the documentation to mention that there is much less overhead now for most use cases except for the caveats mentioned above? Thx! |
We discussed this issue internally and agreed that this is something that we still want to do. |
I just checked the docs that @ppf2 linked to above and the section about disabling |
I think what @colings86 rewrote in #31029 covers the documentation needs here, so I'm going to remove that lable, leaving the deprecation issue open. |
Currently we allow `_field_names` fields to be disabled explicitely, but since the overhead is negligible now we decided to keep it turned on by default and deprecate and ignore the `enable` option on the field type. Closes elastic#27239
Currently we allow `_field_names` fields to be disabled explicitely, but since the overhead is negligible now we decided to keep it turned on by default and deprecate the `enable` option on the field type. This change adds a deprecation warning whenever this setting is used, going forward we want to ignore and finally remove it. Closes #27239
Currently we allow `_field_names` fields to be disabled explicitely, but since the overhead is negligible now we decided to keep it turned on by default and deprecate the `enable` option on the field type. This change adds a deprecation warning whenever this setting is used, going forward we want to ignore and finally remove it. Closes #27239
Now that
_field_names
has basically no overhead anymore (#26930), we should ignore theenabled
setting in 6.x (and log deprecation) and reject it in 7.x, or maybe 8,x if we want to maintain compatibility for templates.cc @colings86
The text was updated successfully, but these errors were encountered: