question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

NEST 6.0 GA: InferMappingFor and ConcreteTypeSelector gone

See original GitHub issue

In 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:closed
  • Created 6 years ago
  • Comments:14 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
russcamcommented, Feb 8, 2018

IIUC, I can also go back to the JsonProperty attribute for my POCO field mapping changes instead of PropertyName

That’s correct, since now Json.NET is responsible for serialization of your documents.

Currently, I see the index name there but nothing I would figure I could key upon for index to POCO type mapping

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.

1reaction
Mpdreamzcommented, Feb 6, 2018

They will be Newtonsoft JOBjects if you use Nest.JsonNetSerializer 😃

Another option is to use: .Search<ILazyDocument>() you can then inspect the hits and call hit.Source.As<T>() or hit.Source.As(Type) in lieu of ConcreteTypeSelector. 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 on ConnectionSettings 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. Reintroducing ConcreteTypeConverter is something we’d like to avoid at all costs.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found