-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional schema registration to Avromatic::Model::Messaging
Module
#163
Comments
Avromatic::Model::MessagingSerialization
ModuleAvromatic::Model::Messaging
Module
Thanks for the feature request @dstrates. Can you elaborate on the use cases where you wouldn't want automatic registration of the schema? Ultimately Avromatic needs some way of resolving the schema to an integer id that can be included in the serialized message. |
The main use case is that some environments rely on centralised schema management, rather than letting producers handle it directly. Optional schema registration would be really helpful to control schema evolution in these environments. I'm not very familiar with Avromatic but I've made a commit here with some quick thoughts. I think we can fetch an existing ID associated with a schema from the registry. Appreciate any input @jturkel |
Makes sense. I'd be open to a PR that implements the changes if you're willing to make changes to avro_turf to expose the necessary schema registry lookup method in |
Also note you can configure |
Feature Request
Update the Avromatic::Model::MessagingSerialization module to make schema registration with the schema registry optional.
Current Behaviour
Currently, the
MessagingSerialization
module automatically registers the Avro schemas (both key and value schemas) with the schema registry when theregister_schemas!
method is called. This behaviour is always on, with no option to disable it.Proposed Change
Introduce a class-level configuration option to control whether schemas should be registered automatically. This will allow developers to opt-in or opt-out of schema registration based on their specific use cases. This could potentially take the form of a class-level variable and methods to toggle the registration behaviour.
The text was updated successfully, but these errors were encountered: