Skip to content
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

Queries are no longer derive from SearchQuery #8182

Closed
feherbbj opened this issue May 6, 2024 · 4 comments
Closed

Queries are no longer derive from SearchQuery #8182

feherbbj opened this issue May 6, 2024 · 4 comments
Labels
8.x Relates to 8.x client version Category: Not an issue

Comments

@feherbbj
Copy link

feherbbj commented May 6, 2024

Elastic.Clients.Elasticsearch version: 8.13.x or 8.14

Elasticsearch version: 8.12.2

.NET runtime version: 8.0

Description of the problem including expected versus actual behavior:
Queries are no longer derive from SearchQuery ( I Mean TermsQuery, WildcardQuery...etc). Is there a reason for that? This way operators (&& or ||) cannot be applied. In earlier versions 8.12.0 or before they did derive from SearchQuery

Expected behavior
All query must derive from SearchQuery

@feherbbj feherbbj added 8.x Relates to 8.x client version Category: Bug labels May 6, 2024
@flobernd
Copy link
Member

flobernd commented May 6, 2024

Hi @feherbbj,

this is a change that was introduced with the new code generator. It was required to be able to generically support similar constructs in our specification.

The container class Query still supports the use of the && and || operators.

The change is documented in the release notes of 8.13.0:
https://github.com/elastic/elasticsearch-net/releases/tag/8.13.0

@flobernd flobernd closed this as completed May 6, 2024
@feherbbj
Copy link
Author

feherbbj commented May 6, 2024

Hi @flobernd ,

Thank you for the answer. I did not notice this breaking change, but even with your response I don't really understands the reason behind it.
It really seems like with every version, there is a step back for the C# API, since the latest 7.16 NEST nuget package. Loosing the mix usage of QueryDescriptor and Query objects, loosing built-in formatters (eg Stack object is deserialized inversed order compare to the original input) and this change could also trigger a lot of extra code. I know this is the situation now and users need to accept it, but the old NEST API was more comfortable to use

@flobernd
Copy link
Member

flobernd commented May 6, 2024

Hi @feherbbj, thanks for the feedback. Maybe this blog post gives you some more insights about the reasons: https://www.elastic.co/search-labs/blog/net-client-evolution

It's basically just one person (me) maintaining the .NET client these days and we had to reduce scope to keep up with the workload. Now that version 8.13.x is released and finally most of the ES server APIs are supported, I can focus on bringing back some of the convenience features (but note, that bringing back NEST features is case by case decision and not everything will make it into the new client).

@feherbbj
Copy link
Author

feherbbj commented May 8, 2024

Thanks for the info! Well that explains a lot. That's rough. Wishing you lots of perseverance then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.x Relates to 8.x client version Category: Not an issue
Projects
None yet
Development

No branches or pull requests

2 participants