Releases: linkedin/avro-util
Releases · linkedin/avro-util
0.4.0
Improve performance of avro codegen
0.3.28
Remove some concurrency and performance bottlenecks in SpecificRecordGenerator
0.3.27
0.3.24
initial impl for AvroRecordUtil.validateNestedSchemasConsistent (#524)
0.3.23
support up to avro 1.11.3, align behaviour on content-beyond-end-of-s…
0.3.22
fix complex default conversion - handle list (#522)
0.3.21: Added fast-avro customization support
Added serde customization support in Fast-Avro (#520) * Added serde customization support in Fast-Avro We have the following requirements: For serialization, we would like to validate whether all the map fields are using the desired map type. For deserialization, we would like to deserialize the map type into a special map impelementation for later use. These customized requirements are not supported in the past because of the following reasons: 1. Fast classes generated are shared, so it is possible different users of the same schema may have different requirement. 2. For the same process, for different schema, the requirements can be different too. 3. No way to specify customized logic/data type when generating fast classes. This PR adds a new functionality to specify customized logic and it is expandable and backward compatible. DatumReaderCustomization : customization for read DatumWriterCustomization : customization for write Currently, these classes only support the requirements mentioned at the beginning. How it works internally? 1. Each Fast DatumReader/DatumWriter constructor will take a new param for customization. 2. Each Fast DatumReader/DatumWriter will keep a local vanilla-Avro based implementation with customization support since the shared vanilla-Avro based implementation is still the default implementation. 3. Each generated Fast class will have a new param for customization in serialize/deserialize APIs. 4. Fast DatumReader/DatumWriter will call this new API with customization param of Fast classes. 5. The read/write API in Fast DatumReader/DatumWriter doesn't change, so it is backward compatible. * Addressed comments * Code gen for #520
0.3.20: fast-avro fail fast support
Adding fail-fast feature to fast-serde (#519) * code cleanup * bugfixes * Generation errors logged on ERROR level. * [fastserde] Adding fail-fast feature.
0.3.19: Logical type support in fast-avro and a few more serde optimization
[fast-avro] Added a few serde optimization (#517) Serializer: This code change will try to reuse the backed bytes if the float list is 'BufferBackedPrimitiveFloatList' when writing float list. If an instance of `BufferBackedPrimitiveFloatList` is changed after deserialization: `readPrimitiveFloatArray`, Fast Serializer won't use the backed bytes because of the divergence. Deserializer: Use `reset` instead of `clear` when reusing `GenericArray` since `reset` is cheaper than `clear` and the behavior difference is that `reset` won't nullify the elements in current array, but just resize the array length to be 0.
0.3.18: Fixed a fast-avro runtime compilation issue
Disable annotation processing in the runtime compiler (#518)