Skip to content

Fix using fastavro if reader schema is None #694

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

Closed
wants to merge 2 commits into from
Closed

Fix using fastavro if reader schema is None #694

wants to merge 2 commits into from

Conversation

treefrog00
Copy link

@treefrog00 treefrog00 commented Oct 17, 2019

  1. Don't attempt to call to_json on reader schema if it's None
    Reader schema is optional, yet currently an exception in calling reader_schema_obj.to_json() will cause the if HAS_FAST: block to raise an exception and hence a fallback to the Python avro implementation

  2. Use json.loads(str(schema)) rather than schema.to_json(), due to confluent-kafka 1.0.0 is incompatible with avro-python3 1.9.0 #610

@ghost
Copy link

ghost commented Oct 17, 2019

It looks like @jamesjrg hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.

Once you've signed reply with [clabot:check] to prove it.

Appreciation of efforts,

clabot

@treefrog00
Copy link
Author

[clabot:check]

@ghost
Copy link

ghost commented Oct 17, 2019

@confluentinc It looks like @jamesjrg just signed our Contributor License Agreement. 👍

Always at your service,

clabot

@rnpridgeon
Copy link
Contributor

Thanks @jamesjrg , I am actually refactoring the avro module this week to eliminate the fallback behavior all together as its a bit messy and I don't believe its needed anymore. It may have been when this client was originally drafted but fastavro appears to support most if not all the things the apache distribution does without the semver headaches.

Moving forward we will provide two avro serializers, Apache and FastAvro which will operate independently of one another. The default however will be Fast Avro. The idea being that we can eventually phase out the apache module all together.

That said have I'd like to ask if you have ever run into a situation where the fallback behavior was actually needed (barring bugs in the fallback logic itself which is a bit messy)?

Thanks,
Ryan

@treefrog00
Copy link
Author

Never needed the fallback behaviour nope! Though did at one point need to pass an extra argument to fastavro to get back union names: fastavro/fastavro@eb53076

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

Successfully merging this pull request may close these issues.

2 participants