You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/06/08 23:33:21 UTC

[jira] [Commented] (BEAM-317) Implement PAssert without using Side Inputs

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

ASF GitHub Bot commented on BEAM-317:
-------------------------------------

GitHub user kennknowles opened a pull request:

    https://github.com/apache/incubator-beam/pull/437

    [BEAM-317] Base PAssert on GBK instead of side inputs

    Be sure to do all of the following to help us incorporate your contribution
    quickly and easily:
    
     - [x] Make sure the PR title is formatted like:
       `[BEAM-<Jira issue #>] Description of pull request`
     - [x] Make sure tests pass via `mvn clean verify`. (Even better, enable
           Travis-CI on your fork and ensure the whole test matrix passes).
     - [x] Replace `<Jira issue #>` in the title with the actual Jira issue
           number, if there is one.
     - [x] If this contribution is large, please file an Apache
           [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt).
    
    ---
    
    Previously `PAssert` - hence all `RunnableOnService`/`NeedsRunner` tests - required side input support. This created a very steep on ramp for new runners.
    
    `GroupByKey` is a bit more fundamental and most backends will be able to group by key in the global window very quickly. So switching the primitive used to gather all the contents of a `PCollection` for assertions should make it a bit easier to get early feedback during runner development.
    
    This exposed issues in a test, which is fixed in a separate commit, should you choose to review them separately.

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

    $ git pull https://github.com/kennknowles/incubator-beam PAssert

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

    https://github.com/apache/incubator-beam/pull/437.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 #437
    
----
commit 239f9f93c17d87b45e1bd7750f483cd2966a9ae8
Author: Kenneth Knowles <kl...@google.com>
Date:   2016-06-08T22:07:52Z

    Base PAssert on GBK instead of side inputs
    
    Previously PAssert - hence all RunnableOnService/NeedsRunner
    tests - required side input support. This created a very steep
    on ramp for new runners.
    
    GroupByKey is a bit more fundamental and most backends will be
    able to group by key in the global window very quickly. So switching
    the primitive used to gather all the contents of a PCollection for
    assertions should make it a bit easier to get early feedback during
    runner development.

commit c17cec636632cdeb5f208bbf2655456b54acdc0f
Author: Kenneth Knowles <kl...@google.com>
Date:   2016-06-08T23:22:34Z

    Fix TriggerExampleTest

----


> Implement PAssert without using Side Inputs
> -------------------------------------------
>
>                 Key: BEAM-317
>                 URL: https://issues.apache.org/jira/browse/BEAM-317
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-java-core
>            Reporter: Thomas Groh
>            Assignee: Kenneth Knowles
>            Priority: Minor
>
> SideInputs are not supported equally by all runners. Implementing assertions as a main input and a serialized assertion allows runner implementors to test their implementations prior to constructing side inputs.
> satisfies is the same, but accumulates the entire input into a single pane which it takes as a main input.
> containsInAnyOrder encodes the expected elements as they need not be serializable, and then can be implemented in terms of satisfies.
> empty can be implemented by failing if provided with any elements, so long as the success counter is not the means by which success is measured.



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