Expose default implementation of CosmosSerializer

[ankitvijay]

Is your feature request related to a problem? Please describe.
The CosmosSerializer class in ComsosDb is currently abstract and all its implementation such as CosmosJsonDotNetSerializer or CosmosTextJsonSerializer are internal sealed. This makes it impossible to extend these serializers in our code. More often than not, we have a need to implement CosmosSerializer in our code. Since there is no default implementation of CosmosSerializer we end up duplicating the ComsosDb SDK internal serializer in our own class.

For example, currently, the only way to supply Newtonsoft JsonSerializerSettings is to implement CosmosSerializer while our only intention is to add custom JsonConverter and initialize properties such as TypeNameHandling, ConstructorHandling, etc.

In addition to this, a default implementation of CosmosSerializer where it gives access to raw JObject/ Stream in derived class can be very useful. In my current project, our custom implementation of CosmosSerializer enables us to do the following things:

• Run schema migrations/ changes on CosmosDocument after it is read from CosmosDB and before it gets deserialized into the C# entity.

From my experience, CosmosDb does not have a great story to tell when it comes to schema migration/ change on rehydration from CosmosDb. A default implementation of CosmosSerializer may just open the door to achieve equivalent to RavenDb events in future.

• Decorate Cosmos document with additional properties such as ttl (while running tests) before saving it to Cosmos.

Describe the solution you'd like

Expose default implementation of CosmosSerializer for Newtonsoft.Json and System.Text.Json.

Here is one example of how we could benefit from the default implementation of CosmosSerializer while creating ComsosClient:

public class CustomCosmosSerializerSettings : JsonSerializerSettings
{
   public CustomCosmosSerializerSettings ()
   {
      // Set Converts, TypeNameHandling etc.
   }
}


var cosmosClient = new CosmosClient(serviceEndpoint, authKey,
                new CosmosClientOptions
                {
                    Serializer = new CosmosDefaultSerializer(new CustomCosmosSerializerSettings()),
                });  // CosmosDefaultSerializer comes from CosmosSDK

Describe alternatives you've considered
Create our own custom implementation of CosmosSerializer inspired by CosmosJsonDotNetSerializer or CosmosTextJsonSerializer

[j82w]

@kirankumarkolli do you see any issue with this? I don't see any reason for it not to be exposed. Even in v4 SDK there will need a easy way for user to plug in Newtonsoft, and I don't see that as a blocker for the v3 SDK.

[scottluskcis]

Created discussion 2064 in hopes to generate some new discussion on this topic

[ghost]

Closing due to in-activity, pease feel free to re-open.

[hades200082]

Still an issue.

[bartelink]

@hades200082 Put notes on #4330 or #4332 if you have specific needs that are not covered by the recent addition of support for STJ name attributes etc

[church365]

Still an issue.

Research shows that for every customer that complains, there are 26 with the same complaint that don't register their complaint. Since we're talking about developers, there may be up to 100 developers out there with this challenge, and they're being ignored. It's probably safe to assume that at least 5%-10% of those 100 work for large platforms, so ultimately there might be millions of users impacted by this seemingly obscure issue. Food for thought, Microsoft.

https://missiveapp.com/blog/customer-service-statistics#how-poor-customer-service-drives-a-negative-experience

[leus]

Please reopen this. We need to prevent Newtonsoft from throwing on certain fields (like deserializing an Exception derived object).

Edit: apparently you can switch to System.Text.Json now, will look into it.