[FEATURE] Support for custom JsonSerializerOptions

[ilya-scale]

Is your feature request related to a problem? Please describe.
I am trying to switch to the new library 8.x, but it does not seem it allows for custom format for Json serialization.

E.g. I need to add a date format, enum conversion, camel case, etc.

Before it was possible to do this:

var connectionSettings = new ConnectionSettings(pool, (serializer, values) =>
{
            return new JsonNetSerializer(serializer, values, () => MySettings); 
}

I did not find anything on how to do it in 8.x.

Describe the solution you'd like
I want a possibility to provide my own options. If required it should be merged with DefaultRequestResponseSerializer if it has some options that have to be present.

Describe alternatives you've considered
It seems it is possible to get to the Options of the default serialiezr like that:

var jsonSerializerOptions = ((SystemTextJsonSerializer) client.RequestResponseSerializer).Options;

I am not sure if it is intended, but it is not possible to replace the options completely, but possible to augment them. It seems a bit strange way of accessing the options and looks more like a side effect than a feature.

[stevejgordon]

Hi, @ilya-scale. We don't currently have a good story for augmenting the existing options. That hook you found won't work for this scenario and shouldn't be exposed publicly. Right now, you'd have to implement a custom Serializer and new it up in the ElasticsearchClientSettings by providing a SourceSerializerFactory. However, you'd not get the built-in converters, so you may hit issues if you use any of our types on your POCO class for the source data.

I have a roadmap item to refine the experience to make it easier to configure JsonSerializerOptions in some form.

[ilya-scale]

Thanks for the answer @stevejgordon , what do I risk if I use the workaround that you have described (since I would rather use it now than wait)? It is only one fairly simple class that I write to the database. There are no references to the library in there.

Do you also have some estimate as to when you will be able to implement this?

[stevejgordon]

Hi, @ilya-scale. For simple POCOs, the custom Serializer will be fine. We'll likely expose most customisation that way but just look to simplify the experience. Deriving a custom serializer is a supported scenario, it's just hard to implement fully at the moment.

I can't provide a specific timeframe for customisation improvements. I can say that I hope to provide something sooner, rather than later as it's a common requirement we want to support more easily.

[ilya-scale]

Thanks, I have written this class, that should support all of the default converters as a workaround:

public class DefaultElasticsearchSerializer : SystemTextJsonSerializer
{
    public DefaultElasticsearchSerializer(Serializer builtInSerializer)
    {
        var builtInSerializerOptions = ((SystemTextJsonSerializer)builtInSerializer).Options;
        
        Options = MyClass.GetDefaultOptions();

        foreach (var converter in builtInSerializerOptions.Converters)
        {
            Options.Converters.Add(converter);
        }
    }
}

[stevejgordon]

@ilya-scale - Be wary of grabbing the converters from the buildInSerializer for now. I noticed a bug, and we're exposing the request/response serializer instead of the source serializer when we invoke the factory. For now, it will add converters that could potentially conflict with your own types. I'll fix that bug in the next patch.

[ilya-scale]

Thanks, do you suggest I should for now just use only my converters instead?

[stevejgordon]

@ilya-scale That might be best for now to avoid any breaks or unexpected behavioural changes until we provide a formal, supported way to configure this.

[ilya-scale]

Thanks for help!

I will do this. It seems to work just fine for my case now, so hopefully you guys will release a fix before I need a more complicated document to be stored :)