[jira] [Commented] (FLINK-9569) Confusing construction of AvroSerializers for generic records

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on FLINK-9569:
---------------------------------------

GitHub user tzulitai opened a pull request:

    https://github.com/apache/flink/pull/6151

    [FLINK-9569] [avro] Fix confusing construction of GenericRecord AvroSerializers

    ## What is the purpose of the change
    
    The `AvroSerializer` previously had a `AvroSerializer(Class<T> type, Schema schema)` public constructor when used for generic records.
    
    This is a bit confusing, because when using the `AvroSerializer`, the type to be serialized should always be a `GenericData.Record` type.
    
    This PR fixes this by letting the `AvroSerializer` having similar construction patterns to the `AvroDeserializationSchema`, where we have static factory methods for generic and non-generic Avro types.
    
    ## Brief change log
    
    - Remove all public constructors from the `AvroSerializer`
    - Add `TypeSerializer<GenericRecord> AvroSerializer.forGeneric(Schema)` method to create an `AvroSerializer` for `GenericRecord`s
    - Add `TypeSerializer<T> AvroSerializer.forNonGeneric(Class<T> type)` method to create an `AvroSerializer` for specific or POJO types.
    - A previously deprecated constructor in the `AvroSerializer` is completely removed, since it should be assumed that the `AvroSerializer` is an internal API and would not require API deprecation.
    
    ## Verifying this change
    
    This is just a code refactor. Required test coverage should not have been effected.
    
    ## Does this pull request potentially affect one of the following parts:
    
      - Dependencies (does it add or upgrade a dependency): (yes / **no**)
      - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: (yes / **no**)
      - The serializers: (**yes** / no / don't know)
      - The runtime per-record code paths (performance sensitive): (yes / **no** / don't know)
      - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / **no** / don't know)
      - The S3 file system connector: (yes / **no** / don't know)
    
    ## Documentation
    
      - Does this pull request introduce a new feature? (yes / **no**)
      - If yes, how is the feature documented? (**not applicable** / docs / JavaDocs / not documented)


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/tzulitai/flink FLINK-9569

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/6151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #6151
    
----
commit 53da570a962226ff81172a209dc1362a0637e110
Author: Tzu-Li (Gordon) Tai <tz...@...>
Date:   2018-06-11T16:04:51Z

    wip

commit 1abbcd13da9f2ac69afc318e121c04d59ee903ec
Author: Tzu-Li (Gordon) Tai <tz...@...>
Date:   2018-06-12T08:43:19Z

    [FLINK-9569] [avro] Fix confusing construction for GenericRecord AvroSerializers

----


> Confusing construction of AvroSerializers for generic records
> -------------------------------------------------------------
>
>                 Key: FLINK-9569
>                 URL: https://issues.apache.org/jira/browse/FLINK-9569
>             Project: Flink
>          Issue Type: Improvement
>          Components: Type Serialization System
>            Reporter: Tzu-Li (Gordon) Tai
>            Assignee: Tzu-Li (Gordon) Tai
>            Priority: Major
>
> The {{AvroSerializer}} currently has a {{AvroSerializer(Class<T> type, Schema schema)}} public constructor when used for generic records.
> This is a bit confusing, because when using the \{{AvroSerializer}}, the type to be serialized should always be a {{GenericData.Record}} type.
> We should either:
> - have a separate subclass of {{AvroSerializer}}, say {{GenericRecordAvroSerializer}} that is a {{AvroSerializer<GenericRecord>}}, or
> - follow a similar approach to the instantiation methods in the {{AvroDeserialiationSchema}}. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)