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.

Upgrade to NEST 7.0 serializer issues.

See original GitHub issue

I upgraded to elasticsearch 7 from 5 and one area that bit me and caused me about a days worth of work was trying to figure out why my models were not being serialized correctly. I was under the impression that in 7.0 that all serializer settings configured were only for my models and that was it. This is where I went wrong…

I injected my applications serializer settings and configured it like this thinking it would use all my serializer settings:

var settings = new ConnectionSettings(connectionPool, 
                (serializer, values) => new JsonNetSerializer(serializer, values, () => _myAppsInjectedSerializerSettings));

After a day of messing around and creating smaller and smaller samples, I found that my injected serializer settings were modified by reference and affected my entire application (NOT Cool). I believe this is being done so NEST Attributes can be resolved (of which we don’t use anywhere in our app and have no plans todo). So I was able to rework the following in one of our apps which got us up and working:

var settings = new ConnectionSettings(
                CreateConnectionPool() ?? new SingleNodeConnectionPool(new Uri(_config.ConnectionString)),
                (serializer, values) => new JsonNetSerializer(serializer, values, JsonSerializerSettingsFactory, ModifyContactResolver, ContractJsonConverters));
            
        private JsonSerializerSettings JsonSerializerSettingsFactory()
        {
            return new JsonSerializerSettings
            {
                DateParseHandling = _serializerSettings.DateParseHandling,
                DefaultValueHandling = _serializerSettings.DefaultValueHandling,
                MissingMemberHandling = _serializerSettings.MissingMemberHandling,
                NullValueHandling = _serializerSettings.NullValueHandling
            };
        }
        
        private void ModifyContactResolver(ConnectionSettingsAwareContractResolver resolver)
        {
            var strategy = ((DefaultContractResolver) _serializerSettings.ContractResolver).NamingStrategy;
            resolver.NamingStrategy = new CamelCaseNamingStrategy(strategy.ProcessDictionaryKeys, strategy.OverrideSpecifiedNames, strategy.ProcessExtensionDataNames);
        }

       private IEnumerable<JsonConverter> ContractJsonConverters => _serializerSettings.Converters;

One of my main concerns about this is that I don’t like that I can’t just use my existing serializer settings and there probably is a lot of properties that I’m not syncing… I’d rather just inject my settings and know it’s the same exact serializer settings. Which brings me to my blocking issue.

In Exceptionless, we have a custom contract resolver that depending on the type we use one serializer or the other (here is where we register the serializer). I don’t even know how I’d modify the contract resolver in this case. I could probably get 80% of the way there with a custom naming strategy but we do custom logic in LowerCaseUnderscorePropertyNamesContractResolver.CreateProperty.

Is there a good way to solve this?

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:11 (11 by maintainers)

github_iconTop GitHub Comments

1reaction
Mpdreamzcommented, Oct 14, 2019

I believe this is being done so NEST Attributes can be resolved (of which we don’t use anywhere in our app and have no plans todo). So I was able to rework the following in one of our apps which got us up and working:

Thats correct: Nest.JsonNetSerializer exists to deal with bits from NET in your source documents such as

  • resolving configured propertynames (attributes/connectionsettings).
  • As well as handling NEST objects that could appear in your source and might need special care:
typeof(JoinField),
typeof(QueryContainer),
typeof(CompletionField),
typeof(Attachment),
typeof(ILazyDocument),
typeof(LazyDocument),
typeof(GeoCoordinate),
typeof(GeoLocation)

If neither apply it could be more beneficial to create your own IElasticsearchSerializer based on Json.Net and return that from the source serializer factory method you pass to ConnectionSettings. That way we don’t bleed into your existing contract resolvers.

1reaction
russcamcommented, Oct 9, 2019

This looks like a manifestation of the recurrent problem that the client needs to make specific modifications to the serializer settings, including the IContractResolver, that could collide with your changes to the serializer settings needed for your application.

You may need to derive from JsonNetSerializer and override CreateContractResolver() to return an IContractResolver that derives from ConnectionSettingsAwareContractResolver which applies any settings that you need, or calls to the base implementation.

I would like to revisit this implementation for 8.x, to see if it’s possible to make these components easier to use and modify.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Custom serialization with 7.0.0 Elasticsearch NEST
The issue was that after upgrading from 6.4.2 to 7.0.0 the way we were ignoring certain properties stopped working so fields which weren't ......
Read more >
Upgrading to Elastic Search NEST 7.0.1 breaks code that ...
I think the message you see tells you everything. Invalid NEST response built from a successful (404) low level call on HEAD: /12- ......
Read more >
Issue with old file in elasticsearch - Questions
This happens when i update the index documents in BackOffice. ... Net\Serialization\DiagnosticsSerializerProxy.cs:line 65 at Nest.
Read more >
Documentation | NestJS - A progressive Node.js framework
Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines ...
Read more >
Invalid NEST response built from a unsuccessful (200) low ...
NET client so I can help. This relates to an issue that was fixed in v7.13.1. The bug unfortunately crept into the 7.13.0...
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