Default values support in codegen

Support for default values were introduced in version 8.0.2 for schema generation, meaning that a class such as this:

public class MyRecord
{
    [DefaultValue(null)]
    public int? Value { get; set; }
}

Produces this schema, with the expected "default": null property:

{
  "type": "record",
  "name": "MyRecord",
  "fields": [
    {
      "name": "Value",
      "type": [
        "null",
        "int"
      ],
      "default": null
    }
  ]
}

What would be great is to also have the opposite. Given schema above, have the generated code include a [DefaultValue] attribute to match the schema. At the moment, here’s what the generated class looks like for the schema above when running dotnet avro generate:

public class MyRecord
{
    public int? Value { get; set; }
}

This is a problem, because any producer who uses that class will now produce a new schema which no longer includes the default value, and potentially start creating compatibility problems in the schema registry.

Could the dotnet avro generate command be updated to support default values from the schemas?

[nicodeslandes]

Sorry for the late reply, I’ve been sidetracked away from Avro these last few days. I’ve got 2 possible suggestions:

1. Handle the “happy” path only, if the default value is null of a scalar, generate the [DefaultValue] attribute correctly. If we’re not in a supported scenario, issue a warning and don’t produce anything.
2. For the unsupported case like the one you highlighted above, still issue a warning, but decorate the property with a new attribute [DefaultSchemaValueJson], which reproduce the default value as it is defined in the originating schema, and is used when producing the schema from the record class.

Option 1 would be good enough for most cases, and would be enough to ensure we have a good story when one team generate a schema from C# code, and another team wants to produce a C# class from that same schema. The 2nd team would be able to used that class without new, potentially incompatible schemas being published to the registry.

Option 2 would even push this further by allowing a producer to handle schemas that don’t come from a generated C# class.

[dstelljes]

Yeah, the schema would just be the JSON string, but DefaultSchemaValueJsonAttribute would have to live somewhere.