As far as I know there's not plan for that, at lease I didn't find a
relevant Jira.
On Wed, Apr 24, 2019 at 4:06 PM Harshvardhan Agrawal <
harshvardhan.ag...@gmail.com> wrote:
> 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 <nkol...@cloudera.com> 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 <
>> harshvardhan.ag...@gmail.com> 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
>
