You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avro 1.8 introduced logical types, including support for timestamps. This was done in a way that allows for backwards compatibility; clients that don't understand logical types simply see the underlying primitive type.
In our case this would mean updating the relevant lines in the schema:
Unfortunately we can't just turn this on due to some issue in Avro's code generation. Specifically, enabling logical types makes the generated code depend on Joda-Time. There's an open issue (addressed by apache/avro#248) that will address this, but it seems to have lost momentum.
At this point I don't think the benefit of the cleaner types is justified by extra dependency on Joda-Time; hopefully it won't be too long before this is addressed.
Avro 1.8 introduced logical types, including support for timestamps. This was done in a way that allows for backwards compatibility; clients that don't understand logical types simply see the underlying primitive type.
In our case this would mean updating the relevant lines in the schema:
{ "name": "timestamp", "type": { "type": "long", "logicalType": "timestamp-millis" }}, { "name": "clientTimestamp", "type": { "type": "long", "logicalType": "timestamp-millis" }},Unfortunately we can't just turn this on due to some issue in Avro's code generation. Specifically, enabling logical types makes the generated code depend on Joda-Time. There's an open issue (addressed by apache/avro#248) that will address this, but it seems to have lost momentum.
At this point I don't think the benefit of the cleaner types is justified by extra dependency on Joda-Time; hopefully it won't be too long before this is addressed.