You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Karapace requires a Kafka cluster for storing schemas. While the topic name can be changed, it creates management / mapping overhead in cases where multiple schema registries are needed, or when schemas are needed outside Kafka, or when dealing with limited HW resources.
Suggestion is to abstract backend storage details and allow different storage plugins to be developed (e.g. relational DB or k/v store).
The text was updated successfully, but these errors were encountered:
The API can be extracted to abstract base class. The point where some extra care is required is the get_schema_id function, when relational database can provide monotonically increasing identifier. Also some locking that protects the schema id generation can also be removed when using database as storage.
Currently Karapace requires a Kafka cluster for storing schemas. While the topic name can be changed, it creates management / mapping overhead in cases where multiple schema registries are needed, or when schemas are needed outside Kafka, or when dealing with limited HW resources.
Suggestion is to abstract backend storage details and allow different storage plugins to be developed (e.g. relational DB or k/v store).
The text was updated successfully, but these errors were encountered: