Several event types per topic

[saabeilin]

Description

There are lots of cases where "on Avro schema per topic" does not work. A good description of the cases and solutions available in Java library is provided here:
https://www.confluent.io/blog/put-several-event-types-kafka-topic/

However, the Python library has "subject = topic + key/value" hardcoded, and even the parameter name in encode_record_with_schema is called topic, not subject.

While this behavior could be overriden in subclasses, would be great to have "NameStrategies" compatible/similar to java client implementation.

[rnpridgeon]

Unfortunately there are some unintended consequences involved in using these alternative naming strategies which may break downstream systems. Kafka Connect in particular relies on the Topic strategy to determine when/if the schema has changed for a particular subject. This enables individual connectors to react to schema evolution events as they are encountered within a topi stream. For example the JDBC's connector needs to evolve it's own schema for a particular topic in the event new fields are added. Having alternatives strategies however breaks this assumption which can break things in unexpected ways. While its true you can still do this with the Java clients I don't think its a good idea to encourage this behavior in other clients without more significant demand from the community.

[saabeilin]

@rnpridgeon No problem, that's already implemented in other libraries.

[soxofaan]

also see #401

[mhowlett]

the support angle is very valid, and maybe enough reason to justify deferring the feature until it will be less problematic with other CP systems, but i think we need to ultimately allow for it. #401 (comment)

[rnpridgeon]

Fair enough. I see your point and given that this will likely be coming to .NET in the near future as well I will reevaluate my decision. I think there are are a few supporting features that may need to come into the picture as well in order to do this truly effective. I need to wrap up 1.0 and a few other things but after that I will put some careful thought into how to make this work given the state of the Avro Python implementation. From there we can reevaluate the existing PRs and make a plan on how to proceed.