Hello Dan and all,
On 1/16/20 7:00 PM, Dan Schmitt wrote:
Only difference I can see is the null default/union possibly not being
handled well by avro_record_set
or avro_record(schema)
Without reading the source I'd expect avro_record(schema) to default
the default union values to null
Yes, I was assuming that a nullable record field would be NULL if no
value was provided.
leading to some sort of let's keep reading this memory issue because
we don't know where the end is.
You can test if that's not happening by setting hours in your original
program, and/or explicitly setting
the fields to null types.
Thank you for this insight ! I wrote a few more variations [1] of my
program:
- with or without nullable fields
- filling them explicitely with avro_null() or a value
- also with another union type: long/double
In the end, I did not manage to have a working program that constructs a
record with an union type, and write it to a file, but it works with
non-union types (see [2]).
Maybe there is an additional step to perform when constructing or
encoding union types in avro-c ?
Probably room for improvement on the C++ side (should validate/throw
if the avro_dataum_t isn't valid
or matching the writer schema instead of doing whatever it's doing, in
addition to having the null/union
default work for avro_record(schema)).
I created a repository with all the variation of my test program:
[1]
https://github.com/titouanc/test-avro-record/tree/bd4f63824489d0b5802cb05bcbd6f9e1b3251a7c
The tests results are visible there:
[2]
https://github.com/titouanc/test-avro-record/commit/bd4f63824489d0b5802cb05bcbd6f9e1b3251a7c/checks?check_suite_id=405071388#step:4:1
Best regards,
Titouan
