DataMember Name is ignored when retrieving documents

[andrewrimmer]

NEST/Elasticsearch.Net version:7.0

Elasticsearch version:7.2

Description of the problem including expected versus actual behavior:

When performing a search the list of documents returned is missing any of the field values when the json field name is different to the c# class member name.

For example, if you have a type with the following property, it is not being returned.

    [DataMember(Name = "city_name")]
    public string CityName { get; set; }

This worked fine in 6.x, and I guess it is as a result of the internal serializer having changed.

All of the c# types that we use with Elasticsearch are kept in an assembly with no dependency on NEST (i.e. they are essentially plain DTOs). If we are to perform a workaround, we would prefer a solution where our DTO classes do not take a dependency on NEST (if that is now possible).

[andrewrimmer]

I have got to the bottom of the issue.

We have a type along these lines:-

public class Order
{
    public GeoIp GeoIp { get; set; } 
}

However the member name in Elastic is geoip all in lower case.

In 6.x the serializer would work it out and map geoip > GeoIp without any extra configuration, however in 7.0 this behaviour has changed.

I changed it to the correct configuration :-

 [DataMember(Name = "geoip")]
 public GeoIp GeoIp { get; set; }

Now everything is working as expected.

[russcam]

Thanks for opening @andrewrimmer, and thank you for also following up.

As you have found, Utf8Json, the internal serializer, is more strict than Json.NET when it comes to casing, and the deserialization of JSON object field names to C# POCO properties. With Json.NET, it will first try an exact match, then fall back to a case insensitive match

https://github.com/JamesNK/Newtonsoft.Json/blob/0ce23ff92459619fde10a5cec0a336ab00a08b4c/Src/Newtonsoft.Json/Serialization/JsonPropertyCollection.cs#L125-L141

With Utf8Json, it only ever tries an exact match, as the serialized member names get hardcoded into a generated IJsonFormatter<T> for the POCO.

I personally think this approach is better and less "magical", and willl perform better, although it is a behavioural change; I will add it to the breaking changes docs to highlight.

Are you good to close this issue?

[codebrain]

Hi @andrewrimmer - you are correct in that the Utf8Json serialiser in 7.0 is stricter with regards to casing.
Given you have resolved the issue are we OK to close this ticket?

[russcam]

Added

• note to blog post
• breaking changes
• release notes

[andrewrimmer]

Thanks @russcam for the background and more information on the issue. I completely agree, the new functionality, although breaking, is an improvement and overall makes things more consistent.