Skip to content

Releases: linkedin/avro-util

0.3.28

11 Jan 22:48
39d884c
Compare
Choose a tag to compare

Remove some concurrency and performance bottlenecks in SpecificRecordGenerator

0.3.27

11 Jan 01:01
26ae2c0
Compare
Choose a tag to compare

revert #525

0.3.24

14 Nov 00:28
39547a2
Compare
Choose a tag to compare
initial impl for AvroRecordUtil.validateNestedSchemasConsistent (#524)

0.3.23

08 Nov 19:25
3b5d833
Compare
Choose a tag to compare
support up to avro 1.11.3, align behaviour on content-beyond-end-of-s…

0.3.22

05 Nov 05:02
b08911b
Compare
Choose a tag to compare
fix complex default conversion - handle list (#522)

0.3.21: Added fast-avro customization support

26 Oct 19:12
cd17a70
Compare
Choose a tag to compare
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

19 Oct 15:45
ab40879
Compare
Choose a tag to compare
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

05 Oct 20:51
d661ed3
Compare
Choose a tag to compare
[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

20 Sep 23:46
917b1b9
Compare
Choose a tag to compare
Disable annotation processing in the runtime compiler (#518)

0.3.17: Fixed a fast-avro large method issue in fast serializer

08 Sep 00:43
b5f3ce6
Compare
Choose a tag to compare
[fast-avro] Added logic to split large method for fast serializer (#514)

In the past, we updated fast deserializer to support large method
splitting, and this code change is leveraging the similar logic to
split large method in fast serializer.