[GitHub] flink pull request #5126: [FLINK-5506] [gelly] Fix CommunityDetection NullPo...

[greghogan <gi...@git.apache.org>]

GitHub user greghogan opened a pull request:

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

    [FLINK-5506] [gelly] Fix CommunityDetection NullPointerException

    ## What is the purpose of the change
    
    This fixes a regression which can result in `NullPointerException` when running the `CommunityDetection` algorithm. When a new highest valued label had a negative summed value the lookup was performed on the old label value which did not necessarily exist in the dictionary.
    
    ## Brief change log
    
    - replaced `Double.MIN_VALUE` with the intended (and original) `-Double.MAX_VALUE`
    - added `Graph#mapVertices` and `Graph#mapEdges` variants accepting `TypeHint` rather than `TypeInformation`; this seemed useful when using Java 8 lambdas which require explicit type definition with OpenJDK
    - added additional tests for `CommunityDetection`
    
    ## Verifying this change
    
    `CommunityDetectionTest#testWithSingletonEdgeGraph` is a user supplied example which fails without the bug fix.
    
    ## 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/greghogan/flink 5506_communitydetection_nullpointerexception

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

    https://github.com/apache/flink/pull/5126.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 #5126
    
----
commit 8d57371616a742ba29548192d5d8a4018cafd26b
Author: Greg Hogan <co...@greghogan.com>
Date:   2017-12-05T17:36:18Z

    [hotfix] [gelly] Graph API mapVertices/mapEdges with TypeHint

commit 8c131b42cfa95df34333a9ca733c9337f75695ba
Author: Greg Hogan <co...@greghogan.com>
Date:   2017-12-05T17:38:50Z

    [FLINK-5506] [gelly] Fix CommunityDetection NullPointerException
    
    Double.MIN_VALUE != min(double)

----


---

[GitHub] flink issue #5126: [FLINK-5506] [gelly] Fix CommunityDetection NullPointerEx...

[greghogan <gi...@git.apache.org>]

Github user greghogan commented on the issue:

    https://github.com/apache/flink/pull/5126
  
    @StephanEwen thanks for the tip. I'll remove the added `TypeHint` methods and commit to 1.4 and 1.5.


---

[GitHub] flink pull request #5126: [FLINK-5506] [gelly] Fix CommunityDetection NullPo...

[asfgit <gi...@git.apache.org>]

Github user asfgit closed the pull request at:

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


---

[GitHub] flink issue #5126: [FLINK-5506] [gelly] Fix CommunityDetection NullPointerEx...

[StephanEwen <gi...@git.apache.org>]

Github user StephanEwen commented on the issue:

    https://github.com/apache/flink/pull/5126
  
    Just a comment on the use of `TypeHint`:
    
    In the `DataSet` and `DataStream` API, we typically pass `TypeInformation` when offering an explicit way to describe the type. The reason is that `TypeInformation` is the core class to describe types, and when you pick up the type from somewhere to pass it on, you get a `TypeInformation`.
    
    The `TypeHint` class is used as a trick to create a `TypeInformation` by capturing the parameters through creating an anonymous subclass. In some way, one could always use `new TypeHint<Tuple2<Long, String>>(){}.getTypeInfo()`, but for convenience, some methods accept directly a `TypeHint`, mainly the `returns(...)` method.
    
    If you take `TypeHint` directly as a parameter, it becomes hard to pass the type if you for example obtain it from another `DataSet` via the `getType()` method.


---