Is your feature request related to a problem? Please describe
Preface:
I run into this question while I was working on #20980 (also see #20963 for more context).
Question:
I can see that IndicesOptions class exposes several predefined IndicesOptions as public static "constants". At the same time there are public static methods that give access to the same constants as well. There does not seem to be any clear indication about what is the preferred access pattern for these predefined IndicesOptions.
After doing a quick scan of the source code it seems that access methods are used more often. Yet there are still several examples where direct access for IndicesOptions constant is used (although it can be replaced the equivalent call to static method).
For instance ResolveIndexTests.java still access constants directly
IndicesOptions indicesOptions = IndicesOptions.LENIENT_EXPAND_OPEN_CLOSED_HIDDEN;
while it could have been using
IndicesOptions indicesOptions = IndicesOptions.lenientExpandHidden();
Since IndicesOptions contract is part of public API I think it should be clear what the recommendation is. Changing all uses of direct constant access to method calls is not a problem IMO. But main question is the API clarity. Perhaps the most important (impactful) it is for plugin authors because if one access pattern is labeled as deprecated then they will be forced to update their code at some point in the future. Yet, maintaining both access patterns (direct access to constant and providing also access method) sounds like confusing API design.
Just my 2 cents, I would prefer access methods because from the long term API maintenance POW it is easier to handle use of deprecated IndicesOptions going forward (deprecation logging or any other "acrobatics" is easier to implement if client is calling methods).
Describe the solution you'd like
Document what is the recommended access pattern for predefined IndicesOptions. Possibly deprecate one of them and consolidate all internal uses of this API.
Related component
Search
Describe alternatives you've considered
No response
Additional context
No response
Is your feature request related to a problem? Please describe
Preface:
I run into this question while I was working on #20980 (also see #20963 for more context).
Question:
I can see that IndicesOptions class exposes several predefined IndicesOptions as public static "constants". At the same time there are public static methods that give access to the same constants as well. There does not seem to be any clear indication about what is the preferred access pattern for these predefined IndicesOptions.
After doing a quick scan of the source code it seems that access methods are used more often. Yet there are still several examples where direct access for IndicesOptions constant is used (although it can be replaced the equivalent call to static method).
For instance
ResolveIndexTests.javastill access constants directlywhile it could have been using
Since IndicesOptions contract is part of public API I think it should be clear what the recommendation is. Changing all uses of direct constant access to method calls is not a problem IMO. But main question is the API clarity. Perhaps the most important (impactful) it is for plugin authors because if one access pattern is labeled as deprecated then they will be forced to update their code at some point in the future. Yet, maintaining both access patterns (direct access to constant and providing also access method) sounds like confusing API design.
Just my 2 cents, I would prefer access methods because from the long term API maintenance POW it is easier to handle use of deprecated IndicesOptions going forward (deprecation logging or any other "acrobatics" is easier to implement if client is calling methods).
Describe the solution you'd like
Document what is the recommended access pattern for predefined IndicesOptions. Possibly deprecate one of them and consolidate all internal uses of this API.
Related component
Search
Describe alternatives you've considered
No response
Additional context
No response