Could not generate a type for the union

[mastery-aparna-kamble-zz]

While generating C# classes from the Avro schema with command - Get-Content .\example-class.avsc | dotnet avro generate | Out-File .\ExampleClass.cs, throwing error - Could not generate a type for the union [RecordSchema, RecordSchema, RecordSchema, RecordSchema]

Sample Schema:

{
"type" : "record",
"name" : "TestEvent",
"namespace" : "net.test",
"doc" : "Wrapper event for test.",
"fields" : [ {
"name" : "event",
"type" : [ {
"type" : "record",
"name" : "Test1",
"fields" : [.. ]
} ]
}, {
"type" : "record",
"name" : "Test2",
"fields" : [ .. ]
}, {
"type" : "record",
"name" : "Test3",
"fields" : [ .. ]
}, {
"type" : "record",
"name" : "Test4",
"fields" : [ .. ]
} ]
} ]
}

[dstelljes]

The exception you’re seeing is being thrown here because the code generator can’t figure out what type the event field should be on the generated class. (You probably want an interface like IEvent, but the generator isn’t smart enough to figure that out.)

Unfortunately, there’s no workaround at this time other than extracting the schemas for each of the child records, generating classes for each one, and manually assembling the top-level class. I’ll leave this issue open as a feature request.

[EricGriffith]

The way the Apache and Microsoft implementations handle this is by generating a field or property of type object and using runtime type information to support serialization.

[dstelljes]

I don’t love the idea of generating fields with object or dynamic types since that wouldn’t really be consistent with the rest of the library; we’d prefer to hew as close as possible to idiomatic C#.

One possible approach could be to offer a couple of behaviors like we do for timestamps:

dotnet avro generate --union-behavior common-fields

To start with, we could have couple obvious options; empty which generates an empty interface type or common-fields which takes common fields from each record type in the union. In either case, if the union was the type of a record field, the interface name could be based on the field name, otherwise fall back to some placeholder.

cc @AllenPorter1986