Github user fhueske commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-103060542
+1 for contrib
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-102952846
I think the options were a to have a `TupleUtil` class either in
- `flink-contirib`
- `flink-java` in a `util` or `lib` subfolder.
I would vote fo
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-102077233
I think the consensus was that we don't want to have such a method in the
DataSet API. We can, however, put a utility for this in flink-contrib. This
utility should work
Github user FelixNeutatz commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-101981739
So, what is the final decision here?
> this seems like a lot of code for something that can be achieved using a
simple mapper
--> that is exactly the re
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-95577570
+1 for not specializing code in the `DataSet`
A `TupleUtil` would be fine, in my opinion
---
If your project is set up for it, you can reply to this email and
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-95566780
Yes, I think we should start a discussion there. I just wanted to give the
reasons for my opinion here.
---
If your project is set up for it, you can reply to this email
Github user fhueske commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-95523597
@aljoscha Those are good points. I like the idea of cleaning the Java and
Scala APIs from operations that work on structured data such as projection,
aggregation, etc. and
Github user rmetzger commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-95522921
I would put this into the `flink-contrib` module.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-95521509
I'm against merging this, to me this seems like a lot of code for something
that can be achieved using a simple mapper. Also, if we add this, then we
should also have a v
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-94918887
I think this is good in general, modulo two issues:
- There are going to be more Utils, to I would like to give it a more
speaking name, like "TupleUtils", or "Tu
Github user fhueske commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-94792842
How do we proceed with this PR?
I think it looks good and would be OK with adding this feature to a
`DataSetUtils` class.
Other opinions?
---
If your project
Github user fhueske commented on a diff in the pull request:
https://github.com/apache/flink/pull/308#discussion_r28776433
--- Diff:
flink-java/src/main/java/org/apache/flink/api/java/lib/DataSetUtil.java ---
@@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Foundati
Github user zentol commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-70413423
@StephanEwen would that look like this?
```java
reverse(dataset.map(...)).filter(...)
```
Ive been thinking about the API overload issue a bit: could a D
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-70412946
This looks like a nice approach.
Concerning the naming/packaging: How about we create a package
`org.apache.flink.api.java.lib` with various classes with utili
Github user rmetzger commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-69976328
+1 for some utilities.
I'm not sure however where to put it.
Should we add another maven module? Make it part of the current
"flink-java" ? Or start it as a github
Github user FelixNeutatz commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-69966273
I am really open about the place of this functionality, but I'd really love
to have it. Shall we start a package in flink-java?
---
If your project is set up for it
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-69965449
I like the idea of having good utilities.
There is always a bit of a trade-off between having the right utilities,
and adding so many functions that the API be
Github user FelixNeutatz commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-69962411
The simple map function implementation reduces the code to 26 lines. I
think that this is more reasonable :)
---
If your project is set up for it, you can reply to
Github user FelixNeutatz commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-69952101
Good question, I thought it would be nice to have it implemented
"natively", but I can also setup the same thing using a simple map function if
this is preferred
--
Github user zentol commented on the pull request:
https://github.com/apache/flink/pull/308#issuecomment-69940866
Why did you make a new operator instead of implementing it as a simple map
function?
---
If your project is set up for it, you can reply to this email and have your
reply
GitHub user FelixNeutatz opened a pull request:
https://github.com/apache/flink/pull/308
[FLINK-1398] Introduce extractSingleField() in DataSet
This is a prototype how we could implement extractSingleField() for
DataSet. Let's discuss :)
You can merge this pull request into a Git r
21 matches
Mail list logo
