I don't know whether this is important because we are talking about the Java API, but for people familiar with Scala or F#, for example, the methods minBy/maxBy make perfectly sense. These methods are part of the standard collection API of the respective language and select the element with the minimum/maximum selected key. Of course, Flink's minBy/maxBy return a DataSet with the element instead of the element itself.
On Fri, Nov 28, 2014 at 6:59 PM, Ufuk Celebi <[email protected]> wrote: > @Stephan: Yap. :) > > I agree with Viktor's suggestions. In order to not break existing programs > I would keep the deprecation annotation as you have in your branch. We > could then remove them in 0.9.0 or so. For minBy/maxBy I would rename it as > you suggested, but keep the old methods and deprecate them as well. > > Maybe someone can comment on the Javadocs changes here: > https://github.com/apache/incubator-flink/pull/244 > > I hope that it makes the API clearer for now. > > On Fri, Nov 28, 2014 at 6:23 PM, Viktor Rosenfeld < > [email protected]> wrote: > >> Hi, >> >> I would drop min/max/sum. I've marked them deprecated in my pull request >> because I did not change their current implementation based on the old >> aggregate. >> >> I think that it makes more sense to have convenience functions like >> countByKey which Sebastian suggested that do encapsulate more complex >> behavior than an aggregation on a single field. >> >> I would also rename minBy/maxBy to selectMin/selectMax or something >> similar >> (selectMinBy?, selectMinByField?) to make their behavior more explicit. >> >> Best, >> Viktor >> >> >> >> -- >> View this message in context: >> http://apache-flink-incubator-user-mailing-list-archive.2336050.n4.nabble.com/Wrong-and-non-consistent-behavior-of-max-tp484p499.html >> Sent from the Apache Flink (Incubator) User Mailing List archive. mailing >> list archive at Nabble.com. >> > >
