steven-aerts commented on PR #3373: URL: https://github.com/apache/avro/pull/3373#issuecomment-2857128003
@KalleOlaviNiemitalo meanwhile I checked all the other language bindings on how they interpret the spec. All the language bindings which have a JSON encoder seem to fully qualify their types. It is only the C binding which deviates here. So this patch lines up this behavior with the other language bindings. | | json union encoding | json union decoding | | ------ | ------------------- | ----------------------------- | | C | unqualified | N/A | | C++ | qualified | qualified | | csharp | qualified [1] | qualified | | java | qualified | qualified | | js | qualified | qualified and unqualified [2] | | perl | N/A | N/A | | PHP | N/A | N/A | | python | N/A | N/A | | ruby | N/A | N/A | | rust | N/A? | N/A? | [1]: possible to configure a non standard encoding where the union value is not wrapped in an object. This variant is not decodable. [2]: where unqualified is [commented in code](https://github.com/apache/avro/blob/main/lang/js/lib/schemas.js#L862) as being less strict. I think this is done, as it is part of the standard flow to encode any javascript object to (binary) avro, giving developers who encode unions a little bit less to type. Again, if you think decoders should, like the js decoder, be more lenient I do not mind to workout a patch for the Java bindings. -- 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]
