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
AvroProducer and AvroConsumer without key schema #608
Comments
there's a general serde API in progress that will address this ( #502 ). work will commence on that again before too long ... |
For now we just created a sub class of the AvroProducer. If someone else needs such a workaround:
|
Now we have the Problem on the Consumer side. When the Java producer sends a message with a key without a Schema, we get an error:
from We do not know whether there is a simple solution like our workaround above. Would you consider that as a bug? |
No string keys for python - confluentinc/confluent-kafka-python#608
I was obtaining
I did my own "AvroCodec" for encoding & decoding messages with an Avro Schema from the schema-registry `
` usage:
dependencies:
|
We're currently still using the patch by @kontrafiktion. Can someone say if it is now possible to use the Confluent Python library without a key schema, i.e. only a value schema? |
@edenhill So the way to go would now be to use a |
yes. apologies that we've been slow to stabilize the new API - we don't anticipate significant changes. |
I ran into the same issue and for the time being, I am using @kontrafiktion's workaround to mitigate my issue. |
Description
Our Java producers send messages with a schema for the value, but use a simple string for the key. The Python AvroProducer does not allow a key without a schema. We cannot simply change the existing Java producers. Is there a way to have the exact same string keys used on the Python side. How must the schema be defined? Or can we get rid of the requirement to have a schema for the key?
How to reproduce
Checklist
Please provide the following information:
confluent_kafka.version()
andconfluent_kafka.libversion()
): ('0.11.6', 722432) ('0.11.6', 722687)The text was updated successfully, but these errors were encountered: