calindima commented on issue #1296: URL: https://github.com/apache/pulsar-client-go/issues/1296#issuecomment-2462061057
> When the client encodes the Avro message, the Avro encoder automatically validates the schema. However, JSON schema encoding works differently. We do not pass the schema definition to the encoder. Instead, we encode from any object type to JSON bytes. The JSON encoder does not perform any validation. This's same for both the GO and Java client. Thanks for pointing it out, it was something that I saw and had me wondering why there's no validation. I can accept that it's similar to the Java implementation which is currently the "standard" for clients, but seems incomplete since schema validation should serve as a contract between producers and consumers, and in the two-folded approach taken to provide this functionality, where the server rejects producers without a valid schema, the producer seems like the place to reject incompatible messages, thus ensuring type safety. I guess there's nothing to do here, since it aligns with Java client. > For client SDKs such as .Net and Java, they can use generics class feature to restrict the type of messages sent or received by the producer or consumer. However, the Go producer and consumer do not use generics. In fact, they are more similar to the Java client's Producer<byte[]>. > Since Go introduced struct generics from go 1.18, it might be worthwhile to implement a similar feature for the Go producer and consumer. Might be a good idea. I found out that although AvroSchema offers the validation we were looking for, you can just override schema completely by using Payload instead of Value to send a message, which means although you create a Schema Producer, you can still publish "trash". Leaves a lot of checks in the hands of producers, instead of having them follow a paved path for this feature. On this note, maybe there are some improvements to be made here? Thanks for taking the time to respond to all of this. I'm trying to understand better the existing functionality, whether there's something we can contribute and what needs to be taken as is. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
