KalleOlaviNiemitalo commented on PR #3436: URL: https://github.com/apache/avro/pull/3436#issuecomment-3511045334
I don't use Avro in Java myself, but I wonder if this should offer an opt-out. Maybe the developer has a class hierarchy only for selecting different in-memory representations and does not intend to encode it as an Avro union. I mean something similar to the .NET class [BufferedLogRecord](https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.abstractions.bufferedlogrecord?view=net-9.0-pp), which implements many of its properties as returning null by default, and derived classes override only those properties for which they are able to return a different value. So when the log buffering implementation gets a log entry and translates that to a BufferedLogRecord, it can choose a derived class at run time, depending on which properties it has been configured to save and whether the actual log entry has non-null values for those properties. (A log entry in .NET may contain references to objects that will be recycled for other purposes after the logging call returns, but before the log buffer is flushed. That's why the log entry cannot be stored in a log buffer as is.) OTOH, BufferedLogRecord is an abstract class, and I imagine a similar thing in Java would likewise be abstract and could not be automatically _deserialized_ from a non-union Avro object, so perhaps types like that are unlikely to be used as Avro data. -- 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]
