Linq provider should respect JsonSerializerSettings ContractResolvers
JsonSerializerSettings are now supported when creating the client, as per https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6422364-allow-me-to-set-jsonserializersettings
However, when using for example a CamelCasePropertyNamesContractResolver to store the data, the linq queries will fail if the properties on the POCO classes are Pascal case.
This is currently not on our roadmap. However, we will continue to review this item in the future as we prioritize future releases.
Thank you for your suggestion.
I wasted few days to figure out this issue. The current workaround is to build stringified SQL query instead of LINQ, which works perfectly with Pascal Cased C# models & camel Cased cosmosdb documents.
Robert Thorne commented
This is not helpful approach as it is at the moment and doesn´t sell CosmosDB well for developers. Very confusing that you have this helpful LINQ search provider, but have to add JSONProperty attributes on all the models to make then queryable, especially when the FeedOptions has a global JsonSerializerSettings property.
Daniel Little commented
This is a very important feature, especially considering https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6422364-allow-me-to-set-jsonserializersettings
Michael Calvin commented
Please get this on the backlog
Morten Mertner commented
Not having this on your roadmap is just disgraceful.
I recommend that everyone steer clear of Cosmos as a storage provider until it supports both idiomatic C# and JSON out of the box.
3 hours.. 3 hours wasted trying to figure out what was wrong. I wish to have my 3 hours back.
Come on guys, this issue really makes our code unreadable and hard to maintain because of the JsonProperty attributes which we have on every POCO-s...
Please prioritize this.
Martyn Norman commented
I've hit this issue too...
Carl Edwards commented
Yes, with the goal of eliminating the annotation on every property for the camel case version of the name either having the LINQ provider respect JsonConvert.DefaultSettings or taking the settings as an argument seems necessary. BTW I am using the .NET Core version of the SDK.
Member names in SQL queries generated from Linq currently look at the member for either a JsonPropertyAttribute or DataMemberAttribute. If the ability to specify custom JsonSerializerSettings is implemented (see http://feedback.azure.com/forums/263030-documentdb/suggestions/6422364-allow-me-to-set-jsonserializersettings ), this will need to be implemented to actually remove the need to annotate every member of your data object classes.