[BUG] fuzziness parameter differs in types dependant on relevance functionc

[forestmvey]

What is the bug?
Parsing accepts types fuzziness and Object dependent on relevance function. This is confusing for developers and when fuzziness is not used as type, an incorrect implementation can be placed on top of the API.

QueryStringQueryBuilder
MultiMatchQueryBuilder
MatchQueryBuilder

What is the expected behavior?
One consistent type should used. fuzziness type would be preferred to ensure valid fuzziness types through the API conformity.

Additional Notes
The main drawback from not using the fuzziness type would be when fulfilling the API a compile time error could be replaced with a run-time error. For example this bug would not be produceable:
PR-668

[noCharger]

This is more of a matter of method signature consistency than of a bug. Here's the trade-off between taking Fuzziness class everywhere VS take Object everywhere (discussed with @msfroh offline):

Take Fuzziness class everywhere (QueryStringQueryBuilder way)

• Pros:
  • Complie-time validation of an input value that must be of the Fuzziness typed object.
  • API is more self-documenting (since an API that takes Object could mean anything).
• Cons:
  • Requires code change by REST high-level client users who were passing a string or number (ex: "Auto", 0, 1, 2)
  • REST high-level client users must create Fuzziness object by calling Fuzziness.build() or invoke static variables like Fuzziness.ZERO, which is on a class marked @opensearch.internal

Take Object everywhere (MultiMatchQueryBuilder way) - Recommanded

• Pros:
  • Backward-compatible with existing behavior.(If someone is already passing a Fuzziness , it will still work based on Fuzziness.build() implementation)
  • Reduces need for users to use Fuzziness.build() directly, which is good since it’s marked @opensearch.internal.
• Cons:
  • API is less self-documenting.
  • Makes it easier to pass invalid values that only show up at runtime (The querybuilders also marked @opensearch.internal so not recommanded to call it directly from users)

[Yury-Fridlyand]

Why not to have both options?

[noCharger]

Why not to have both options?

Object is more general, and Fuzziness.build() takes object as input already

[macohen]

fixed by #5433