[jira] [Commented] (FLINK-4257) Handle delegating algorithm change of class

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

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

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

GitHub user greghogan opened a pull request:

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

    [FLINK-4257] [gelly] Handle delegating algorithm change of class

    Replaces Delegate with NoOpOperator.

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

    $ git pull https://github.com/greghogan/flink 4257_handle_delegating_algorithm_change_of_class

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

    https://github.com/apache/flink/pull/2474.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 #2474
    
----
commit f8d1aa966ba907b2e3a306f5fe498ed8ac886656
Author: Greg Hogan <co...@greghogan.com>
Date:   2016-07-25T13:09:27Z

    [FLINK-4257 to be squashed] [gelly] Handle delegating algorithm change of class
    
    A class created by ProxyFactory can intercept and reinterpret method
    calls using its MethodHandler, but is restricted in that
    
    * the type of the proxy class cannot be changed
    * method return types must be honored
    
    We have algorithms such as VertexDegree and TriangleListing that change
    return type depending on configuration, even between single and dual
    input functions. This can be problematic, e.g. in OperatorTranslation
    where we test dataSet instanceof SingleInputOperator or dataSet
    instanceof TwoInputOperator.
    
    Even simply changing operator can be problematic, e.g.
    MapOperator.translateToDataFlow returns MapOperatorBase whereas
    ReduceOperator.translateToDataFlow returns SingleInputOperator.
    
    Making changes only within Gelly we can append a "no-op" pass-through
    MapFunction to any algorithm output which is not a SingleInputOperator.
    And Delegate can also walk the superclass hierarchy such we are always
    proxying SingleInputOperator.
    
    There is one additional issue. When we call DataSet.output the
    delegate's MethodHandler must reinterpret this call to add itself to the
    list of sinks.

commit 3209b05ab5575aba08f9cd6284b720ef9dfc5a02
Author: Greg Hogan <co...@greghogan.com>
Date:   2016-07-25T13:41:31Z

    [FLINK-4257] [gelly] Handle delegating algorithm change of class
    
    Replaces Delegate with NoOpOperator.

----


> Handle delegating algorithm change of class
> -------------------------------------------
>
>                 Key: FLINK-4257
>                 URL: https://issues.apache.org/jira/browse/FLINK-4257
>             Project: Flink
>          Issue Type: Bug
>          Components: Gelly
>    Affects Versions: 1.1.0
>            Reporter: Greg Hogan
>            Assignee: Greg Hogan
>
> A class created by {{ProxyFactory}} can intercept and reinterpret method calls using its {{MethodHandler}}, but is restricted in that
> * the type of the proxy class cannot be changed
> * method return types must be honored
> We have algorithms such as {{VertexDegree}} and {{TriangleListing}} that change return type depending on configuration, even between single and dual input functions. This can be problematic, e.g. in {{OperatorTranslation}} where we test {{dataSet instanceof SingleInputOperator}} or {{dataSet instanceof TwoInputOperator}}.
> Even simply changing operator can be problematic, e.g. {{MapOperator.translateToDataFlow}} returns {{MapOperatorBase}} whereas {{ReduceOperator.translateToDataFlow}} returns {{SingleInputOperator}}.
> I see two ways to solve these issues. By adding a simple {{NoOpOperator}} that is skipped over during {{OperatorTranslation}} we could wrap all algorithm output and always be proxying the same class.
> Alternatively, making changes only within Gelly we can append a "no-op" pass-through {{MapFunction}} to any algorithm output which is not a {{SingleInputOperator}}. And {{Delegate}} can also walk the superclass hierarchy such we are always proxying {{SingleInputOperator}}.
> There is one additional issue. When we call {{DataSet.output}} the delegate's {{MethodHandler}} must reinterpret this call to add itself to the list of sinks.



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