epalace commented on pull request #965: URL: https://github.com/apache/avro/pull/965#issuecomment-709511428
> A non-nullable field can still be null if it's unset, so None for that field would indicate that the record isn't (yet) valid. The semantics around this is pretty inelegant -- I don't think it's ever possible to distinguish between an unset field and field set to null. Oh, I see, that's because of the mutable nature of SpecificRecord and when they are built they might still not be valid. [Avrohugger](https://github.com/julianpeeters/avrohugger) addresses this initializing always the non-nullable fields with a default value in its non-args constructor (do not know what are the implications in performance in case that inner objects are not reused in serialization). > You are correct, a separate CompilerOpt object and class would be a nice refactor and cleanup, but not necessary to add this feature. If you feel like taking it on, please feel free! I could tackle that in a different PR. > It's a bit irritating that the tests add 2K lines of code. If anyone can think of a way to improve this in terms of readability and maintainability, I'd love to hear it. Similarly to how the maven plugin works, what about compiling those tests avscs and make the generated output be part of the test sources? Tests would be able to access them in compile time and check the existence and signature of some methods of those generated classes. Something similar to what that they do in sbt-avro [sbt-avro](https://github.com/sbt/sbt-avro/pull/41/files) but without requiring reflection. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
