kafkaflow icon indicating copy to clipboard operation
kafkaflow copied to clipboard

[Feature Request]: Make ConfluentProtobufTypeNameResolver more flexible on type name construction

Open nazarii-piontko opened this issue 1 year ago • 0 comments

Is your request related to a problem you have?

Here is a current version of ConfluentProtobufTypeNameResolver.ResolveAsync:

public async Task<string> ResolveAsync(int id)
{
	var schemaString = (await this.client.GetSchemaAsync(id, "serialized")).SchemaString;

	var protoFields = FileDescriptorProto.Parser.ParseFrom(ByteString.FromBase64(schemaString));

	return $"{protoFields.Package}.{protoFields.MessageType.FirstOrDefault()?.Name}";
}

The issue is that in "multi-language" products/projects (this is my case), Package might be empty or different from CsharpNamespace.

As a result SchemaRegistryTypeResolver cannot resolve the Type.

Describe the solution you'd like

I see a few possible solutions:

  • The simplest one, when protoFields.Package is null or empty use protoFields.Options.CsharpNamespace. This solution is not generic but solves my issue ;)
  • Inject some delegate (via a new config object or whatever) which allows overriding type name construction logic.
  • Allow to register IAsyncSchemaRegistryTypeNameResolver in DI and use the registered one instead of hardcoding concrete implementation.

The final solution might combine some of the suggested solutions above.

Are you able to help bring it to life and contribute with a Pull Request?

Yes

Additional context

No response

nazarii-piontko avatar Jun 15 '23 11:06 nazarii-piontko