Description
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!