I think Stephan meant Meteor, an old API when Flink was Stratosphere. This
was never part of the code that made it to Apache.
Not sure if we want to remove the common API, as it provides a dataflow
abstraction that is higher level than the JobGraph. Admittedly, I don't
have a better argument
I think the main difference to the Java API is right now that the JavaAPI
is fluent and the common API is compositional. Otherwise there is not much
in the common API any more.
Not sure whether this warrants an extra API...
On Wed, Apr 22, 2015 at 3:52 PM, Kostas Tzoumas ktzou...@apache.org
Originally, we had multiple Apis with different data models: the current
Java API, the record api, a JSON API. The common API was the data model
agnostic set of operators on which they built.
It has become redundant when we saw how well things can be built in top of
the Java API, using the
Thanks for the explanation, Stephan. I always wonder why the extra
common APIs exist.
Then I think this should be high priority if we want to remove the
common API to reduce the unnecessary layer and dead code. As Ufuk
mentioned before, better doing it now before more stuff build on top
of Flink.
Since we are talking about common API, what was the original intention
or design for this layer?
From the doc:
The Common API operator exists only in order for the flink-java and
flink-scalapackages to not have a dependency on the optimizer.
Currently the Java API Operator is converted into
Okay, it seems the consensus forms around not breaking the API.
When it comes to the *OperatorBase - should we rename them or simply get
rid of them (remove the common API). If we want to remove them, a
precondition is to remove the Record API, and for that, we should migrate
the Record-API-based
I share Stephans opinion.
By the way, we could also find a common name for operators with two
inputs. Sometimes it's TwoInputXXX, DualInputXXX,
BinaryInputXXX... pretty inconsistent.
On 15.04.2015 17:48, Till Rohrmann wrote:
I would also be in favour of making the distinction between the
+1 for keeping the API. Even though this will not change your initial
concern much, Aljoscha :) I agree with you that it would be more consistent
to call the result of an operator OperatorDataSet.
On Thu, Apr 16, 2015 at 3:16 PM, Fabian Hueske fhue...@gmail.com wrote:
Renaming the core
Renaming the core operators is fine with me, but I would not touch API
facing classes.
A big +1 for Timo's suggestion.
2015-04-16 6:30 GMT-05:00 Timo Walther twal...@apache.org:
I share Stephans opinion.
By the way, we could also find a common name for operators with two
inputs. Sometimes
On 15 Apr 2015, at 14:11, Aljoscha Krettek aljos...@apache.org wrote:
This is just a personal annoyance and I think we are to advanced to
change this now, but here goes: Could we rename the classes in the
API, so that for example MapOperator becomes MapDataSet or MapSet, and
the actual
I think we can rename the base operators.
Renaming the subclass of DataSet would be extremely api breaking. I think
that is not worth it.
Am 15.04.2015 14:11 schrieb Aljoscha Krettek aljos...@apache.org:
This is just a personal annoyance and I think we are to advanced to
change this now, but
I would also be in favour of making the distinction between the API and
common API layer more clear by using different names. This will ease the
understanding of the source code.
In the wake of a possible renaming we could also get rid of the legacy code
org.apache.flink.optimizer.dag.MatchNode
12 matches
Mail list logo
