-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
8.15.6 - TermQuery / TermsQuery inconsistencies and feedback #8345
Comments
Hi @niemyjski ,
I agree from a developers perspective. These APIs are generated from our specification and in this particular case,
Unfortunately, we are running into a C# limitation here, because of the collection.
FieldValue[] ids = ["a", "b", "c"]; // Collection elements are implicitly converted to FieldValue (one by one)
TermsQueryField term = ids; // FieldValue[] is implicitly converted to TermsQueryField but this one does not: string[] ids = ["a", "b", "c"];
TermsQueryField term = ids; // The compiler does not know how to convert `string[]` to TermsQueryField The only solution for this problem would be to generate transitive implicit conversion operators:
While this is possible in theory, it could quite easily cause the generation of 100 or 1000 conversion operators (depending on how deeply nested the hierarchy gets). Besides that, we would have a problem if e.g. For these reasons, this is most likely a: won't fix from my side. The easiest workaround would be to use a collection of Please let me know what you think. |
Edit: I just noticed, that the implicit conversion operators on our |
I'd optimize for the common use cases, add constructor overloads for TermsQueryField that take different collections and automatically creates field values and or I'd do implicit conversions for the type like you said. I don't think we should be limited by code generation (I've been working on a commercial code generation product for over 15 years). |
This issue is stale because it has been open 5 days with no activity. Remove stale label or comment or this will be closed in 2 days. |
Related to #7716 |
Actually closing this as a duplicate of #7716. If we implement that feature on code generator level (specifically to the |
Elastic.Clients.Elasticsearch version: 8.15.6
Elasticsearch version: 8.15.1
.NET runtime version: 8.x
Operating system version: Any
Description of the problem including expected versus actual behavior:
I noticed a lot of inconsistencies / verbosity when converting to the new api's. I feel like the old one was more consistent and easy to use.
Previous
New
Expected behavior
It doesn't make any sense why these are so much different, and all the extra casts (no implicit conversion for field values).
Reference: FoundatioFx/Foundatio.Parsers#84
The text was updated successfully, but these errors were encountered: