elastic / elasticsearch-net

This strongly-typed, client library enables working with Elasticsearch. It is the official client maintained and supported by Elastic.
https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/index.html
Apache License 2.0
11 stars 1.15k forks source link

Improve usability of `FiltersAggregation` #8242

Open flobernd opened 5 months ago

flobernd commented 5 months ago

Currently it's only possible to use Anonymous Filters with the FiltersAggregation:

var q = await client.SearchAsync<Person>(s => s
    .Aggregations(aggs => aggs
        .Add("my_agg", agg => agg
            .Filters(a => a.Filters(new Buckets<Query>([
                Query.MatchAll(new MatchAllQuery()),
                Query.MatchAll(new MatchAllQuery())
            ])))
        )
    )
);

Using named filters throws an exception during deserialization of the results:

var q = await client.SearchAsync<Person>(s => s
    .Aggregations(aggs => aggs
        .Add("my_agg", agg => agg
            .Filters(a => a.Filters(new Buckets<Query>(new Dictionary<string, Query> // <- Dictionary instead of Array
            {
                { "a", Query.MatchAll(new MatchAllQuery()) },
                { "b", Query.MatchAll(new MatchAllQuery()) }
            })))
        )
    )
);

To improve usability, we have to automatically set the keyed argument to true, if the user requests named results.

Besides that, FiltersBucket currently misses the key field in the specification.

Related to #7844

hubilation commented 3 months ago

Worth noting that NEST treated these as separate operations. "Filters" vs "NamedFilters". Coming across this threw a wrench in our migration efforts.

braveyp commented 1 month ago

Is there a roadmap / timeframe for when this will be implemented? I know there's a workaround to simply not use named filters but wasn't sure of the position of the 'other' bucket in the results.

Also, is there a time frame for when a fluent interface will be added for the specification of filter queries?

flobernd commented 1 month ago

Is there a roadmap / timeframe for when this will be implemented? I know there's a workaround to simply not use named filters but wasn't sure of the position of the 'other' bucket in the results.

I'm currently in the procress of prioritizing the "usability" issues. Btw.: The order of the resulting buckets is always the same as for the input ones. Overflow/other should be on the very end.

Also, is there a time frame for when a fluent interface will be added for the specification of filter queries?

This is currently tracked in #7812