MultiSearch for fluently built descriptors in NEST 8

[tdoman]

Elastic.Clients.Elasticsearch version:
8.17

Elasticsearch version:
8.12.2

.NET runtime version:
.NET Standard 2.0

Description of the problem including expected versus actual behavior:
We're looking to migrate from NEST 7 to NEST 8. We're currently using NEST 7 in compatibility mode against ES 8.

In NEST 7, we used fluent syntax to build SearchDescriptor for single searches and were able to use that same shape to build for MultiSearch. In NEST 8, there doesn't appear to be support for that for multi-search, only initializer syntax and a different shape to boot. Here's a look at the operative code we currently have with NEST 7 where I built an abstraction ToSearchDescriptor that expects SearchDescriptor (now SearchRequestDescriptor) to be produced so that I could mix and match any queries I wanted. This works great!

var results = await _client.MultiSearchAsync(selector: ms =>
{
	foreach (var scopedSearch in scopedSearchParams)
	{
		var sp = scopedSearch.SearchParams;
		ms = ms.Search<ILazyDocument>(s => sp.ToSearchDescriptor(_indexConfiguration, scopedSearch.IndexType));
		if (sp.CaptureSearch)
		{
			ms = ms.RequestConfiguration(r => r.DisableDirectStreaming());
		}
		if (_searchOptions.ErrorTrace || sp.ErrorTrace)
		{
			ms = ms.ErrorTrace();
		}
	}
	return ms;
});

Do you plan to support this style of multi-search in the future? All of our search parameter implementations are built on the fluent syntax so this is a big commitment but it's not clear the direction we should go. It looks like if we re-wrote all of those (no small task) to use initializer syntax (ie. SearchRequest), we could manufacture the multi-search shape but even that shape change is confusing now. I expect it has something to do w/ the header for each search but, as shown above, this magic was handled for us and we could be consistent in our abstraction. That is, any implementation that produced a SearchDescriptor didn't know or care whether it was used for a single or multi-search. Very nice!

[flobernd]

Hi @tdoman ,

this sadly seems to be one of the places where the new generated client lacks a bit of the convenience of NEST. There is no trivial solution for this problem, since SearchRequest and SearchRequestItem are two completely distinct types in the specification that is used to generate the client.

I will keep this issue as a reminder to make sure fluent syntax for multi-search is correctly generated in the future.

To support interchangability of the two objects, we could implement an implicit conversion operator from SearchRequest{Descriptor} to SearchRequestItem{Descriptor}. However, this would require specialized generator code (to make it future proof/easily maintainable for the case that new fields get added to the search request types) just for this case and I can't promise that we want to go that route.

An alternative to unblock you, would be to write your own convert method (this is pretty much about mapping all properties of SearchRequest 1:1 to the corresponding counterparts in MultisearchHeader and MultisearchBody).

Another alternative would be to always use multi-search in all places, even if it only contains a single search item.

[tdoman]

Right, if fluent syntax was supported for multi-search, I could probably then take your last suggestion as well and always perform a multi-search hidden behind my abstraction. The implementors then always produce a MultiSearchDescriptor (or whatever it would be called).
In the absence of that, your last suggestion sounds best but that's a lot of code refactoring for us to get off fluent. ☹

[flobernd]

9.0 is around the corner (a few weeks). I'll hope to add fluent support in that release. It will contain quite a few improvements related to descriptors anyways.

[tdoman]

All right, that'd be great to see. I like the cleanness of the composition style approach in NEST 8, I just ran into this roadblock. Keep me posted!