Skip to content
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

Register schema with fixed identifiers #194

Open
ImFlog opened this issue Jan 26, 2025 · 1 comment
Open

Register schema with fixed identifiers #194

ImFlog opened this issue Jan 26, 2025 · 1 comment

Comments

@ImFlog
Copy link
Owner

ImFlog commented Jan 26, 2025

To give a bit more background information on my use case:

I'm using (some) of these schemas in combination with e.g. ksqlDB. I provide schema IDs for all of my queries so that I can very finely control the evolution of the queries in my clusters.

In the above example, a successful schema registration would (given the above order) end up with the following schema IDs: {A: 1, B: 2, C: 3}. In actuality, since only B and C were successful, I end up with the following schema IDs: {B: 1, C: 2}, with A receiving ID 3 once the error is fixed.

I provide the subjects in a deterministic order (notwithstanding the bug I had during initial development :) ). Ideally, I would like this to have the effect that all my schemas have the same schema ID across all environments that I use them in. Perhaps this is too strict of a requirement?

Originally posted by @filpano in #186

@ImFlog
Copy link
Owner Author

ImFlog commented Jan 26, 2025

@filpano For the custom Identifier are you talking about the subject subject id or version ?

If it's the subject version we can specify the subject ID while registering as well as the version -> https://github.com/confluentinc/schema-registry/blob/35f13ce604347a6eb437ff722b2c79b687640fad/client/src/main/java/io/confluent/kafka/schemaregistry/client/CachedSchemaRegistryClient.java#L425 but it is not possible to normalize while sending the subject ID and version manually: https://github.com/confluentinc/schema-registry/blob/35f13ce604347a6eb437ff722b2c79b687640fad/client/src/main/java/io/confluent/kafka/schemaregistry/client/CachedSchemaRegistryClient.java#L437

I could ask on the Confluent side if it would make sense to add a new overload to class in order to have all the parameters available.

Did I understand your use case correctly ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant