NEST 6.0 GA: InferMappingFor and ConcreteTypeSelector gone
See original GitHub issueIn this PR, can now map clr types dynamically on connection settings including an…, I got an InferMappingFor() API that takes two parameters. Namely,
public TConnectionSettings InferMappingFor(Type documentType, Func<ClrTypeMappingDescriptor, IClrTypeMapping> selector)
It was there through RC1 but in the GA, it’s gone. Where’d it go? Do I have to go back to the workaround described here: ConnectionSettings.MapDefaultTypeIndices in NEST 6.x?
Issue Analytics
- State:
- Created 6 years ago
- Comments:14 (5 by maintainers)
Top Results From Across the Web
NEST and Elasticsearch.Net 6.0: Now GA!
Today we are pleased to announce the General Availability (GA) release of our .NET clients for Elasticsearch 6.x.
Read more >NEST Breaking Changes | Elasticsearch .NET Clients [7.17]
This lists all the binary breaking public API changes between NEST 6.8.0, the last 6.x version released when 7.0 went GA release, and...
Read more >c# - Enumerating dynamic hits result using NEST 6.0 for ...
With NEST 6.x, the dependency on Json.NET is IL merged and internalized within the client. This has been done for a number of...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
That’s correct, since now Json.NET is responsible for serialization of your documents.
We’ve been discussing how best to handle this scenario. One thought is to have an index pattern -> CLR type mapping, but still need to let it bake.
They will be
Newtonsoft
JOBjects
if you useNest.JsonNetSerializer
😃Another option is to use:
.Search<ILazyDocument>()
you can then inspect the hits and callhit.Source.As<T>()
orhit.Source.As(Type)
in lieu ofConcreteTypeSelector
. Hope this unblocks you for the time being.Another reason for getting rid of
ConceteTypeSelector
and built in covariance is that internally it dictated the necessity for stateful serializers which introduced a very complex code path as we need to piggy back state into a contractresolver which brought in all sorts of challenges as sharing the contract resolver is key to performance so newing one for every stateful search is bad (something we mitigated by doing additional caching based onConnectionSettings
inside our contract resolver.Having a completely simplified serialization flow internally opens us up to work on OOTB performance and allocation during the course of
6.x
. ReintroducingConcreteTypeConverter
is something we’d like to avoid at all costs.