Even though we don't support iteration, one could have a known upperbound and "unroll" the loop to a fixed number of iterations statically before the pipeline is run but I agree with Eugene on his other points.
On Fri, Jun 7, 2019 at 3:59 AM Robert Burke <[email protected]> wrote: > I'm not sure I understand the desired properties of GroupByMultiKey. > > Offhand, am I right interpreting GroupByMultiKey as essentially forming a > graph of the keys based on the MultiKeys nodes, and the number of resulting > iterables is based on the components of the graph. > > If that's the case then, what does the integer do when creating the > GroupByMultiKey? > > In the example, it seems to be saying "I'd like 3 groups" but wouldn't > that be a property of the implicit connected graphs of MultiKeys? > > Thank you very much! > > > On Fri, Jun 7, 2019, 10:14 AM Jan Lukavský <[email protected]> wrote: > >> Hi, >> >> that sounds interesting, but it seems to be computationally intensive >> and might not be well scalable, if I understand it correctly. It looks >> like it needs a transitive closure, am I right? >> >> Jan >> >> On 6/7/19 11:17 AM, i.am.moai wrote: >> > Hello everyone, nice to meet you >> > >> > I am Naoki Hyu(日宇尚記). a developer live in Tokyo. I often use scala and >> > python as my favorite language . >> > >> > I have no experience with OSS development, but as I use DataFlow at >> > work, I want to contribute to the development of Beam. >> > >> > In fact, there is a feature I want to develop, and now I have the >> > source code on my local PC. >> > >> > The feature I want to create is an extension of GroupBy to a multiple >> > key, which realizes more complex grouping. >> > >> > https://issues.apache.org/jira/browse/BEAM-7358 >> > >> > Everyone, could you give me an opinion on this intent? >> > >> >
