Support `include_named_queries_score` in search requests

[EgbertW]

Description

Elasticsearch 8.8.0 added the feature to return scores for named queries.

Earlier versions can have a _name field for queries that will result in a property matched_queries to be added to the JSON response. Setting the new flag include_named_queries_score changes matched_queries from a list List<String> to Map<String, Double>.

The Java Elasticsearch client currently does not support setting this parameter on the request (although it can be made to by using TransportOptions and the response does not support it because it returns List<String> for matchedQueries() on a Hit object.

It would be nice if the Elasticsearch Java client supports it.

References:
elastic/elasticsearch#94564
https://www.elastic.co/guide/en/elasticsearch/reference/8.8/query-dsl-bool-query.html#named-queries

[oli-tu]

The named query scoring is a cool feature, that would really help me in my current project. Is there any plan to get this into the Java client soon?

[l-trotta]

Hello, after discussing it within the team we have decided that the static language clients (Java, .NET, Go) won't support this feature. The added complexity of a return type that can change depending on a parameter on the request would be extremely convoluted to implement in a stateless context, and it would make the current implementation much more difficult to use.

[EgbertW]

Hi @l-trotta - sorry, I missed your response a year later ;)

I would like to ask you to reconsider - why add a feature to the server if you are not going to support it in the API? Static language clients can also deal with polymorphic responses - the intermediate JSON layer deals with this quite well. At least I know Jackson does - the Elasticsearch Java client uses. Jakarta JSON - having no experience with that I can't state how hard/easy that would be.

However, it could just as well be supported by changing the response API - either align the two different return types (the simpler can adapted to support the more complicated one), or add another optional property to the response type that deals with the adjusted requirements.

We are currently working around this by using the explain feature on the query and manually parsing the scoring from that, but that is very cumbersome and not the best for performance so quite some resource usage would be saved by getting this to work.

[l-trotta]

Hey @EgbertW, I get your points. Polymorphism here wouldn't be possible, not because of the language itself, but because we try to guarantee serialization and deserialization to/from json, and in this case it wouldn't be possible - there's no way to tell if matched_queries would be an Array or a Map. I do like the idea of the adapting the simpler type to the more complex one - so in this case the result would always be a Map, with the value set as 0 by default and then actually set as the score when include_named_queries_score is set to true. Usually it wouldn't be possible to introduce such a breaking change, but with a major version coming up, we could actually make this change. How does this sound, would it solve the problem?

[EgbertW]

Hi @l-trotta, that sounds perfect to me. The major version being 9.0? That'd definitely help us out.