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

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

                Author: ASF GitHub Bot
            Created on: 28/Jul/22 05:02
            Start Date: 28/Jul/22 05:02
    Worklog Time Spent: 10m 
      Work Description: complone commented on PR #1790:
URL: https://github.com/apache/avro/pull/1790#issuecomment-1197665255

   > TestAllCodec#testCodec
   
   In TestAllCodec#testCodec snappyCodec can be added normally and CodeFactory 
is not empty




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

    Worklog Id:     (was: 795919)
    Time Spent: 50m  (was: 40m)

> Fix the problem that CodeFactory is null when specifying snappy format when 
> java Client compresses data
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AVRO-3590
>                 URL: https://issues.apache.org/jira/browse/AVRO-3590
>             Project: Apache Avro
>          Issue Type: Bug
>          Components: java
>    Affects Versions: 1.10.0
>            Reporter: xingyuan cheng
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.10.0
>
>         Attachments: image-2022-07-27-16-10-17-970.png, 
> image-2022-07-27-16-10-33-410.png, image-2022-07-27-16-10-42-262.png, 
> image-2022-07-27-16-11-46-218.png
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> When flink-avro writes data in batches based on the avro format, the general 
> user will specify snappy compression. However, in the avro-1.10.0 version, 
> the Codec and CodeFactory are returned by directly applying for the object, 
> so that the user cannot obtain it Information for SnappyCodec.
> I refer to the practice of ```NullCodec```, changing it to a global variable 
> way will work fine
>  
> !image-2022-07-27-16-10-17-970.png!
>  
> Before repair:
> !image-2022-07-27-16-10-42-262.png!
>  
>  
> after Repair:
>  
> !image-2022-07-27-16-11-46-218.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to