[
https://issues.apache.org/jira/browse/BEAM-11087?focusedWorklogId=667129&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-667129
]
ASF GitHub Bot logged work on BEAM-11087:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 19/Oct/21 16:49
Start Date: 19/Oct/21 16:49
Worklog Time Spent: 10m
Work Description: jrmccluskey commented on a change in pull request
#15743:
URL: https://github.com/apache/beam/pull/15743#discussion_r732062482
##########
File path: sdks/go/pkg/beam/core/runtime/exec/window.go
##########
@@ -96,3 +96,23 @@ func (w *WindowInto) Down(ctx context.Context) error {
func (w *WindowInto) String() string {
return fmt.Sprintf("WindowInto[%v]. Out:%v", w.Fn, w.Out.ID())
}
+
+// WindowMapper defines an interface maps windows from a main input window
space
+// to windows from a side input window space. Used during side input
materialization.
+type WindowMapper interface {
+ MapWindow(w typex.Window) (typex.Window, error)
+}
+
+type windowMapper struct {
+ wfn *window.Fn
+}
+
+func (f *windowMapper) MapWindow(w typex.Window) (typex.Window, error) {
+ candidates := assignWindows(f.wfn, w.MaxTimestamp())
+ if len(candidates) == 0 {
+ return nil, fmt.Errorf("failed to map main input window to side
input window with WindowFn %v", f.wfn.String())
+ }
+ // Return latest candidate window in terms of event time (only relevant
for sliding windows)
+ // Sliding windows append the latest window first in assignWindows.
+ return candidates[0], nil
Review comment:
So the Python comment of "last candidate" also generates them backwards.
Got it. Explicitly calling out behavior in terms of event time is much clearer.
The current implementation of getting the first element in the slice matches
the comment and intent from what I understood at the time, but fixing it isn't
a big issue (apart from updating the tests to reflect that difference)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 667129)
Time Spent: 1h 20m (was: 1h 10m)
> [Go SDK] Validate Side Input behavior WRT windows
> --------------------------------------------------
>
> Key: BEAM-11087
> URL: https://issues.apache.org/jira/browse/BEAM-11087
> Project: Beam
> Issue Type: Sub-task
> Components: sdk-go
> Reporter: Robert Burke
> Assignee: Jack McCluskey
> Priority: P3
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> DoFns with Side inputs implicitly observe windows, as Side Inputs are scoped
> to a current window, a powerful feature of beam.
> The ideal would be to you could try to unit test this in the exec package,
> creating a fake side input adapter (or use the real one), to more directly
> target the implementation.
> [https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/core/runtime/exec/sideinput.go#L34]
> and exercising the ParDo code for Side Input handling directly.
> [https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/core/runtime/exec/pardo.go#L38]
>
> Then it should be possible to bolster that with appropriate mock windows to
> ensure that side inputs are configured correctly.
> Altnernatively this behavior could be tested and validated with an
> integration test against real runners due to the complexity around Side
> Inputs making unit testing a challenge. (While side input code could be
> tested in that fashion, it's likely dramatically simpler to do the
> integration test.)
> Some light tests with Side Inputs already exist, but they're purely in the
> Global Window. Add tests for non-global windows to ensure that Side Inputs
> are scoped correctly.
> Integration test directory:
> [https://github.com/apache/beam/tree/master/sdks/go/test/integration/primitives]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
