Feature/explicit read

[martintaraz]

Modifications on the python source code for working with an explicit given read schemata for decoding avro messages
for tesing purposes, the integration where ran against a docker kafka build

[ghost]

It looks like @martintaraz 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

[martintaraz]

[clabot:check]

[ghost]

It looks like @martintaraz 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

[martintaraz]

[clabot:check]

[ghost]

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

Always at your service,

clabot

[rnpridgeon]

Thanks for this, I have left a few comments mostly around removing .travis.yml changes and removing unrelated formatting changes.

I have to ask though what is the use case for setting the reader schema here. On the surface this seems like a way to handle forward-compatible changes. If that is the case allowing the Schema Registry enforce compatibility constraints seems like a more robust solution for this situation.

https://docs.confluent.io/current/avro.html#forward-compatibility

[rnpridgeon]

All changes to .travis.yml should be removed from this commit

[rnpridgeon]

Please remove any integration test changes not related to the pull request itself. This helps to keep the commit history clean. If you wish to submit a PR which cleans up formatting, white space and imports I'd be happy to review and merge however :)

[fkaufer]

I have to ask though what is the use case for setting the reader schema here. On the surface this seems like a way to handle forward-compatible changes. If that is the case allowing the Schema Registry enforce compatibility constraints seems like a more robust solution for this situation.

@rnpridgeon No, it's about actually taking advantage of Avro's back-/forward compatibility features for which you need to be able to separate writer and reader schema. Before the change, the reader schema was (implicitly) hard-coded to the writer schema (of the respective message), now the consumer can pin a reader schema with the fastavro deserializer doing back or forward schema migration to the reader schema. The Schema Registry only enforces that the sequence of published Avro schemas for a certain topic complies with back-/forward compatibility constraints.

[rnpridgeon]

@fkaufer you are absolutely correct, I had only considered the ability to parse the message. Sorry about that. Other than the .travis.yml changes it LGTM. If you could back those out it would be greatly appreciated.

[fkaufer]

@fkaufer you are absolutely correct, I had only considered the ability to parse the message. Sorry about that. Other than the .travis.yml changes it LGTM. If you could back those out it would be greatly appreciated.

@rnpridgeon Reverted the .travis.yml and other non-related changes in #470

[rnpridgeon]

Fixed with #470