[ 
https://issues.apache.org/jira/browse/AVRO-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417546#comment-17417546
 ] 

Guðjón commented on AVRO-3197:
------------------------------

Hey, thanks for the quick response. I just tried it out, and it works perfectly 
well for the weather.avro file that I included (y) I also tried it on one of 
the files that sparked this issue but it failed giving a similar error message. 
The current error is somehow related to how the avro writer wrote the schema. 
Looking at the schema written in the file I see one field like this
{code:json}
{"name":"occurred_at","type":{"type":"string","avro.java.string":"String"},"logicalType":"timestamp-millis"}
{code}
This is what is causing the current issue. I am not sure if this would fall 
under 
{noformat}
If this is the desired behavior then I will do the same for the other logical 
types and add test cases
{noformat}

One thing I would say is that the way avro-rs handled logical types should be 
how the other libraries handle it as well i.e. failing if the logicaltype and 
type don't match. Thus it might be good (if possible) to have this optionally 
turned on.


> Rust: Disable logical type on failure
> -------------------------------------
>
>                 Key: AVRO-3197
>                 URL: https://issues.apache.org/jira/browse/AVRO-3197
>             Project: Apache Avro
>          Issue Type: Wish
>            Reporter: Guðjón
>            Assignee: Martin Tzvetanov Grigorov
>            Priority: Minor
>              Labels: pull-request-available
>         Attachments: weather.avro
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> I have a file containing avro records along with a schema. The schema 
> contains a field that unfortunately has the type `String` but logical type 
> `timestamp-millis`. The Java implementation of the avro spec doesn't complain 
> and simply treats this field as a string, but the rust implementation will 
> return an error since the string type doesn't match with the logical type of 
> timestamp (long). 
> I wonder if there could be a possibility to optionally disregard the logical 
> type if this failure is encountered.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to