I had pretty much in mind what Aljoscha suggested.

On Thu, Nov 12, 2015 at 11:37 AM, Aljoscha Krettek <aljos...@apache.org>
wrote:

> IMHO it’s not possible to have streaming/batch specific ExecutionConfig
> since the user functions share a common interface, i.e.
> getRuntimeContext().getExecutionConfig() simply returns the same type for
> both.
>
> What could be done is to migrate batch/streaming specific stuff to the
> ExecutionEnvironment and keep the ExecutionConfig strictly for stuff that
> applies to both execution modes.
> > On 12 Nov 2015, at 11:35, Maximilian Michels <m...@apache.org> wrote:
> >
> > +1 for separating concerns by having a StreamExecutionConfig and a
> > BatchExecutionConfig with inheritance from ExecutionConfig for general
> > options. Not sure about the pre-flight and runtime options. I think
> > they are ok in one config.
> >
> > On Wed, Nov 11, 2015 at 1:24 PM, Robert Metzger <rmetz...@apache.org>
> wrote:
> >> I think now (before the 1.0 release) is the right time to clean it up.
> >>
> >> Are you suggesting to have two execution configs for batch and
> streaming?
> >>
> >> I'm not sure if we need to distinguish between pre-flight and runtime
> >> options: From a user's perspective, it doesn't matter. For example the
> >> serializer settings are evaluated during pre-flight but they have a
> impact
> >> during execution.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Nov 11, 2015 at 11:59 AM, Stephan Ewen <se...@apache.org>
> wrote:
> >>
> >>> Hi all!
> >>>
> >>> The ExecutionConfig is a bit of a strange thing right now. It looks
> like it
> >>> became the place where everyone just put the stuff they want to somehow
> >>> push from the client to runtime, plus a random assortment of conflig
> flags.
> >>>
> >>> As a result:
> >>>
> >>>  - The ExecutionConfig is available in batch and streaming, but has a
> >>> number of fields that are very streaming specific, like the watermark
> >>> interval, etc.
> >>>
> >>>  - Several fields that are purely pre-flight time relevant are in
> there,
> >>> like whether to use the closure cleaner, or whether to force Avro or
> Kryo
> >>> serializers for POJOs.
> >>>
> >>> Any interest in cleaning this up? Because these messy classes simply
> grow
> >>> ever more messy unless we establish a proper definition of what its
> >>> concerns and non-concerns are...
> >>>
> >>> Greetings,
> >>> Stephan
> >>>
>
>

Reply via email to