Hi Nandor, Thanks for the response. The hack seems fine for now but is there a tactical fix planned for handling this use case?
Regards, Harsh On Wed, Apr 24, 2019 at 04:55 Nandor Kollar <[email protected]> wrote: > 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* >> > -- Regards, Harshvardhan
