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

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

GitHub user twalthr opened a pull request:

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

    [FLINK-3042] [FLINK-3060] [types] Define a way to let types create their 
own TypeInformation

    Thanks for contributing to Apache Flink. Before you open your pull request, 
please take the following check list into consideration.
    If your changes take all of the items into account, feel free to open your 
pull request. For more information and/or questions please refer to the [How To 
Contribute guide](http://flink.apache.org/how-to-contribute.html).
    In addition to going through the list, please provide a meaningful 
description of your changes.
    
    - [x] General
      - The pull request references the related JIRA issue ("[FLINK-XXX] Jira 
title text")
      - The pull request addresses only one issue
      - Each commit in the PR has a meaningful commit message (including the 
JIRA id)
    
    - [ ] Documentation
      - Documentation has been added for new functionality
      - Old documentation affected by the pull request has been updated
      - JavaDoc for public methods has been added
    
    - [x] Tests & Build
      - Functionality added by the pull request is covered by tests
      - `mvn clean verify` has been executed successfully locally or a Travis 
build has passed
    
    This PR introduces so-called `TypeInfoFactory`s. A type information factory 
allows for plugging-in user-defined TypeInformation into the Flink type system. 
The factory is called during the type extraction phase if the corresponding 
type has been annotated with `TypeInfo` or registered globally using 
`TypeExtractor.registerFactory(Type, Class)`.
    In a hierarchy of types the closest factory will be chosen while traversing 
upwards, however, a globally registered factory has highest precedence.
    
    Although this PR further increases the complexity of the `TypeExtractor`. 
`TypeInfoFactory`s could simplify the code in future. We could implement 
factories for all Flink built-in types and thus split up the extraction code 
into type specific factories.
    
    I haven't updated the doc yet. I will add documentation after I got 
feedback.

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

    $ git pull https://github.com/twalthr/flink FLINK-3042

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

    https://github.com/apache/flink/pull/2337.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 #2337
    
----
commit 3481cf4da45292fcbf541e0ecd885a663373837b
Author: twalthr <twal...@apache.org>
Date:   2016-08-04T15:01:08Z

    [FLINK-3042] [FLINK-3060] [types] Define a way to let types create their 
own TypeInformation

----


> Define a way to let types create their own TypeInformation
> ----------------------------------------------------------
>
>                 Key: FLINK-3042
>                 URL: https://issues.apache.org/jira/browse/FLINK-3042
>             Project: Flink
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.10.0
>            Reporter: Stephan Ewen
>            Assignee: Timo Walther
>             Fix For: 1.0.0
>
>
> Currently, introducing new Types that should have specific TypeInformation 
> requires
>   - Either integration with the TypeExtractor
>   - Or manually constructing the TypeInformation (potentially at every place) 
> and using type hints everywhere.
> I propose to add a way to allow classes to create their own TypeInformation 
> (like a static method "createTypeInfo()").
> To support generic nested types (like Optional / Either), the type extractor 
> would provide a Map of what generic variables map to what types (deduced from 
> the input). The class can use that to create the correct nested 
> TypeInformation (possibly by calling the TypeExtractor again, passing the Map 
> of generic bindings).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to