Hi, Indeed, the problem is with the duplicated longs in the union, schema parser considers only the physical, and not the logical type. My only idea (though a bit ugly) for this case is to use named types like records for the timestamp in the union, I think if you wrap the timestamp into a record, that could work, however the additional record wrapper adds more complexity to the code.
On Wed, Apr 24, 2019 at 5:33 AM Harshvardhan Agrawal < [email protected]> wrote: > Hello, > > We have a use case where one of the fields in our POJO is a Map<String, > Object>. The values of this map could be any of the native types (Int, > Long, String, etc.). We will also have use cases where the object could be > a Date or Timestamp. Since Date and Timestamp are logical types that are > represented as Int and Long respectively and we want to support Ints and > Long as native datatypes, we don't really know how to represent this in > Avro format. We tried something like this: > > {"type":"map","values":["int","long","float","double","string","boolean", > { "type" : "long", "logicalType" : "timestamp-micros"}]} > > We are unable to parse this schema since we have two long types here. If > we remove the long datatype and just keep the logical type entry, we will > end up treating all longs as timestamps which we don't want. Do you have > any idea about this and how should we proceed? > -- > > *Regards,Harshvardhan Agrawal* >
