That sounds good to me. Although making the key copy implicit might confuse users who need to take that into account when specifying the type of data sets of operators...
Taking the key(s) from the Grouping should not be a problem. 2014-11-04 15:12 GMT+01:00 viktor.rosenfeld <viktor.rosenf...@tu-berlin.de>: > Hi Fabian, > > > Fabian Hueske wrote > > DataSet<Tuple2<String, Integer>> ds = ... > > DataSet<Tuple4<String,Integer, Integer, Long> result = > > ds.groupBy(0).key(0).andMin(1).andMax(1).andCnt(); > > > > The second example explicitly extracts the key > > from the original input data. > > Wouldn't it make sense to use the call to groupBy() to also extract the key > fields? So in your example, the call to key(0) is redundant. If there are > multiple fields specified in groupBy() then all of them would be used as > the > key. If the user only wants a specific key, he can specify them by > explicitly calling the key() method. Specifying a field in key() that is > not > used in groupBy() would be an error. This is close to (proper) SQL > semantics. > > What do you think? > > I'm not a big fan of how MySQL let's you specify attributes that are not > grouped or averaged and returns a random element for them. (I think that's > a > bug in MySQL, although there's probably a reason for the behavior.) > > Best, > Viktor > > > > -- > View this message in context: > http://apache-flink-incubator-mailing-list-archive.1008284.n3.nabble.com/Hi-Aggregation-support-tp2311p2359.html > Sent from the Apache Flink (Incubator) Mailing List archive. mailing list > archive at Nabble.com. >