[ https://issues.apache.org/jira/browse/AVRO-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17132924#comment-17132924 ]
Tom Zöhner commented on AVRO-2670: ---------------------------------- Your case 3 seems to be fixed with avro 1.9.2 for the {{date}} type. If I define the following required field: {code:java} { "name" : "date", "type" : { "type" : "int", "logicalType" : "date" }, "doc" : "The date in days from the epoch on 1 January 1970." } {code} The correct java code is generated: {code:java} /** The date in days from the epoch on 1 January 1970. */ private java.time.LocalDate date; {code} If I use the type {{timestamp-millis}} or {{timestamp-micros }}(on a required long) I get the same issue you observed: the type becomes {{java.lang.Object}}. > Inconsistent data types for logicalType = date > ---------------------------------------------- > > Key: AVRO-2670 > URL: https://issues.apache.org/jira/browse/AVRO-2670 > Project: Apache Avro > Issue Type: Bug > Components: java, logical types > Affects Versions: 1.9.1 > Reporter: Marcel Stokman > Priority: Major > > When defining a date field in the avro schema the generated java class files > contains different types based on the given types. > > Giving a schema that contains date's, some are optional and some required. > {code:java} > { > "type": "record", > "name": "DateData", > "namespace": "com.keylane.ics.data", > "fields": [ > { > "name": "dateAsInt", > "type": "int", > "logicalType": "date" > }, > { > "name": "dateAsOptionalInt", > "type": [ > "null", > "int" > ], > "logicalType": "date" > }, > { > "name": "dateAsObject", > "type": [ > { > "type": "int", > "logicalType": "date" > } > ] > }, > { > "name": "dateAsOptionalLocalDate", > "type": [ > "null", > { > "type": "int", > "logicalType": "date" > } > ] > } > ] > } > {code} > > The generated class file defines the 4 fields with different java types > > {code:java} > @Deprecated public int dateAsInt; > @Deprecated public java.lang.Integer dateAsOptionalInt; > @Deprecated public java.lang.Object dateAsObject; > @Deprecated public java.time.LocalDate dateAsOptionalLocalDate; > {code} > > We would prefer to have the type as a LocalDate, so that case 3 and 4 give > the same field definition. > > Is this a bug or should the schema definition be different (and how)? > -- This message was sent by Atlassian Jira (v8.3.4#803005)