flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: About Operator and OperatorBase
Date Mon, 20 Apr 2015 23:09:58 GMT
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 common APIs via
recursive call from ExecutionEnvironement#createProgramPlan which
delegate it to OperatorTranslation.
Just wanted to know more about why the original approach is taking this route.

Thanks,

- Henry

On Fri, Apr 17, 2015 at 5:47 AM, Stephan Ewen <sewen@apache.org> wrote:
> 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 test cases.
>
> Stephan
>
>
> On Thu, Apr 16, 2015 at 6:32 PM, Maximilian Michels <mxm@apache.org> wrote:
>
>> +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 <fhueske@gmail.com> wrote:
>>
>> > 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 <twalthr@apache.org>:
>> >
>> > > 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 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 and
>> > >> rename org.apache.flink.runtime.operators.MatchDriver into JoinDriver
>> to
>> > >> make the naming more consistent.
>> > >>
>> > >> On Wed, Apr 15, 2015 at 3:05 PM, Ufuk Celebi <uce@apache.org>
wrote:
>> > >>
>> > >>  On 15 Apr 2015, at 15:01, Stephan Ewen <sewen@apache.org> wrote:
>> > >>>
>> > >>>  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.
>> > >>>>
>> > >>> Oh, that's right. We return MapOperator for DataSet operations.
>> > Stephan's
>> > >>> point makes sense.
>> > >>>
>> > >>
>> > >
>> >
>>

Mime
View raw message