flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kostas Tzoumas <ktzou...@apache.org>
Subject Re: About Operator and OperatorBase
Date Wed, 22 Apr 2015 13:52:35 GMT
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 other than "it might be useful some day" and happy
to change my opinion :-)


On Tue, Apr 21, 2015 at 5:49 PM, Henry Saputra <henry.saputra@gmail.com>

> 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.
> So removing old Record API [1] and the tests depending on them is step
> one of the process, but what is JSON API?
> - Henry
> [1] https://issues.apache.org/jira/browse/FLINK-1681
> On Tue, Apr 21, 2015 at 1:10 AM, Stephan Ewen <sewen@apache.org> wrote:
> > 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 TypeInformation. Now, Scala, Python, Dataflow,
> all
> > build on top of the Java API.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message