You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2022/01/05 11:28:00 UTC

[jira] [Work logged] (AVRO-3224) Wrong deserialisation when using ReflectData.AllowNull with custom LogicalType conversions

     [ https://issues.apache.org/jira/browse/AVRO-3224?focusedWorklogId=703884&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-703884 ]

ASF GitHub Bot logged work on AVRO-3224:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 05/Jan/22 11:27
            Start Date: 05/Jan/22 11:27
    Worklog Time Spent: 10m 
      Work Description: opwvhk commented on a change in pull request #1355:
URL: https://github.com/apache/avro/pull/1355#discussion_r778746120



##########
File path: lang/java/avro/src/main/java/org/apache/avro/reflect/ReflectDatumReader.java
##########
@@ -287,6 +288,26 @@ protected void readField(Object record, Field field, Object oldDatum, ResolvingD
             return;
           }
         }
+
+        if (field.schema().isUnion()) {

Review comment:
       You've pulled handling the union up from `readWithoutConversion`.
   This means that handling fields like this works, but if the dates are in an array of unions, it will fail (see the method `readArray` starting at line 125).
   
   It's probably better to put this logic in an overridden version of `GenericDatumReader#read(Object, Schema, ResolvingDecoder)`, which is called from `readWithoutConversion`. Granted, this applies conversion inside a method named "without conversion", but _the current implementation already does (buggy) conversions for unions_, so we won't be off worse.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@avro.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 703884)
    Time Spent: 0.5h  (was: 20m)

> Wrong deserialisation when using ReflectData.AllowNull with custom LogicalType conversions
> ------------------------------------------------------------------------------------------
>
>                 Key: AVRO-3224
>                 URL: https://issues.apache.org/jira/browse/AVRO-3224
>             Project: Apache Avro
>          Issue Type: Bug
>          Components: java
>    Affects Versions: 1.10.2
>            Reporter: Du Liu
>            Priority: Minor
>              Labels: pull-request-available
>         Attachments: ReflectData.AllowNull.get doesnt work.png, ReflectData.get works.png, class_and_conversion.png, tests.txt
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> If a class contains both a java.time.LocalDate field and a java.sql.Date field, serialising an instance of the class using ReflectData.*AllowNull* with two conversions that both convert to avro date logical type (e.g. one converts java.time.LocalDate to avro date, the other converts java.sql.Date to avro date) is done correctly, but when deserialising the data back, the LocalDate field of the deserialised instance incorrectly contains a java.sql.Date (or the Date field incorrectly contains a LocalDate depending on which conversions is added last).
> This only happens when using ReflectData.*AllowNull*.get(). ReflectData.get() can correctly deserialised data back. I think this issue affects other types as long as two java types are mapped to the same avro logical type.
> A working example (using ReflectData.get()):
> !ReflectData.get works.png|width=887,height=379!
>  
> A not working example (using ReflectData.AllowNull.get()):
> !ReflectData.AllowNull.get doesnt work.png|width=831,height=469!
> The class and conversion: 
> !class_and_conversion.png|width=798,height=687!
>  
> These tests are included in the attached patch file:  [^tests.txt]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)