DefaultMappingFor IndexName is not respected in searches about elasticsearch-net HOT 3 CLOSED

@Genide The behavior of 8.13.12 is the intended behavior. 8.13.11 had a bug that caused the index to be inferred. The versions prior to 8.13.x as well do not infer the index here and there is a reason for that.

So, why don't we want to infer the index in this case?

Inferring the index for mandatoy IndexName (singular) arguments is not an issue, because these arguments are required to execute the query. At the same time, the query always operates on a single index (e.g. the default index for the entity) which means there is no ambiguity in using the configured default index.

Inferring the index for optional Indices (plural) arguments is problematic. Usually these are used in endpoints where you can either set different indices on operation/element level (e.g. MultiGet, MultiSearch, Bulk, ...) or to generally restrict the action to specific indicies (note, that in these cases, it's completely valid to specify no index as an alternative to all). Examples for this would be the mentioned Search endpoint.

One of our main principles is to prefer explicit over implicit. If we would infer an index here, this would cause unexpected behavior, if you have multiple entities of e.g. Branch stored in different indices. You would have to "undo" the implicit changes by settings the optional indices argument to all. The default way (again, note that the "indices" argument is optional) for Search is to query all indices.

I'm going to close this issue here, but feel free to add further comments or open new issues, if you have other concerns.

from elasticsearch-net.

Then is the use of TConnectionSettings DefaultMappingFor<TDocument> and ClrTypeMappingDescriptor<TDocument> IndexName obsolete?

from elasticsearch-net.

@Genide No, it's still working - just not for optional Indices pararameter 🙂 It works for all other cases like e.g. Get or most index management APIs, etc.

from elasticsearch-net.