Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Open
nazarii-piontko opened this issue Jun 15, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@nazarii-piontko
Copy link

nazarii-piontko commented Jun 15, 2023

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

1 participant