reuvenlax commented on pull request #12915: URL: https://github.com/apache/beam/pull/12915#issuecomment-721332587
+1 IMO it would be useful if it somehow happened prior to the CGBK, but since it's after a subsequent ParDo or Filter will likely be fused anyway. On Tue, Nov 3, 2020 at 11:23 AM Tyson Hamilton <[email protected]> wrote: > I am a bit confused about the usage of compareFn here. State is per key, > so I believe that your DoFn will only join items that have the same key - > the compareFn will never even get to compare items with different keys. Is > the idea to allow the user to generate a subset of an equijoin? > > Yes, it will be a subset of an equijoin. Sorry for the confusion. > > I am a bit confused about the usage of compareFn here. State is per key, > so I believe that your DoFn will only join items that have the same key - > the compareFn will never even get to compare items with different keys. Is > the idea to allow the user to generate a subset of an equijoin? > > Yes, it will be a subset of an equijoin. Sorry for the confusion. > > Now that i'm thinking about this further, the compareFn may be > unnecessarily complicating the API for this join. I imagined it would be > helpful for a user who wants to add logic before emitting a matched result, > like a filter, but it would be more idiomatic for the user to apply a > filter transform to the join result instead. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/apache/beam/pull/12915#issuecomment-721328234>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFAYJVLK76ST2YWOMQGMURLSOBKEJANCNFSM4RXFYIIQ> > . > ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
