As an user, I don’t like “casting option”. Because people who need set parallelism after CoGroup will certainly fall into this issue. They will subconsciously think Flink does not support this feature. We can’t assume most users will read JavaDocs and document carefully.
Maybe we can post this mail to the user list, and listen whether most users can accept the “casting” work-around and which work-around they prefer. > 在 2016年8月8日，下午10:45，Robert Metzger <rmetz...@apache.org> 写道： > > Thank you for bringing this discussion to the mailing list. > > I agree with Chesnay's comment on GitHub that we should consider the > "casting option" as well. I don't think we should break the API if there is > a (admittedly ugly) work-around for those who run into the problem. > If we put the work-around into the JavaDocs and the DataStream API > documentation, everybody who is seriously blocked by this should find it. > > For 2.0, we can break the API by changing the method signature. > > > On Mon, Aug 8, 2016 at 4:11 PM, Stephan Ewen <se...@apache.org> wrote: > >> Hi all! >> >> We have a problem in the *DataStream API* around Windows for *CoGroup* and >> *Join*. >> These operations currently do not allow to set a parallelism, which is a >> pretty heavy problem. >> >> To fix it properly, we need to change the return types of the coGroup() and >> join() operations, which *breaks the binary compatibility* - it* retains >> source compatibility*, though. >> >> The pull request with the change is: >> https://github.com/apache/flink/pull/2305 >> >> There are very clumsy ways to work around this (custom casts in the user >> code or making the join() / coGroup() behave differently than the other >> operators) which we did not really think of as viable, because they would >> need to be changed again in the future once we pull the API straight >> (breaking even source compatibility then). >> >> *I would suggest to actually break the API* at that point (binary, not >> source) for *Flink 1.2* and add a big note in the release docs. An >> uncomfortable step, but the alternatives are quite bad, too. >> >> Have a look at what has been suggested in the pull request discussion and >> please let us know what you think about that so we can proceed. >> >> Greetings, >> Stephan >>
