I am in principle with Ufuk on that, but let's not rush this into the
release. It is not a public API after all.
On Thu, Jun 4, 2015 at 5:23 PM, Ufuk Celebi wrote:
>
> On 04 Jun 2015, at 17:02, Maximilian Michels wrote:
>
> > I think ResultPartition is a pretty accurate description of what it i
On 04 Jun 2015, at 17:02, Maximilian Michels wrote:
> I think ResultPartition is a pretty accurate description of what it is: a
> partition of the result of an operator. ResultStream on the other hand,
> seems very generic to me. Just because we like to think of Flink nowadays
> as a "streaming
I think ResultPartition is a pretty accurate description of what it is: a
partition of the result of an operator. ResultStream on the other hand,
seems very generic to me. Just because we like to think of Flink nowadays
as a "streaming data flow" engine, we don't have to change the core
classes' na
On 04 Jun 2015, at 13:10, Maximilian Michels wrote:
> Rename what to streams? Do you mean "ResultPartition" => "StreamPartition"?
Exactly along those lines, but maybe "ResultStream".
> I'm not sure if that makes it easier to understand what the classes do.
It fits better into the terminology
Rename what to streams? Do you mean "ResultPartition" => "StreamPartition"?
I'm not sure if that makes it easier to understand what the classes do.
On Mon, Jun 1, 2015 at 10:11 AM, Aljoscha Krettek
wrote:
> +1
> I like it. We are a streaming system underneath after all.
> On Jun 1, 2015 10:02 AM
+1
I like it. We are a streaming system underneath after all.
On Jun 1, 2015 10:02 AM, "Ufuk Celebi" wrote:
> I would like to get this done with the upcoming release to have a stable
> name for the documentation.
>
> Thinking about the names with Stephan, he had a great suggestion to rename
> the
I would like to get this done with the upcoming release to have a stable
name for the documentation.
Thinking about the names with Stephan, he had a great suggestion to rename
them to "streams".
I like this idea very much. The supported result variants make more sense
when you think about them as
+1 for the renaming proposed by Ufuk.
@Stephan: At the moment, the IntermediateDataSet is tight to a JobVertex.
So the renaming makes sense. In the future, it might be constructed
differently. Only then, JobVertexResult wouldn't make sense anymore. I'm
not sure if that will even happen.
4) Result
To summarize so far: all are in favor of a rename. I agree with both of
Henry's points regarding the docs.
@Stephan: what would you suggest? I would trust your gut feeling on this
one. ;) JobResult, ExecutionJobResult, ExecutionResult, etc.?
On Tue, Mar 31, 2015 at 8:16 PM, Henry Saputra
wrote:
As one of the devs that recently been tracing the runtime portion of
the code +1 for renaming for inlining with the concepts.
One thing I would like to have is immediate change to the
documentation [1] with renaming PR . Otherwise
Then need to file followup ticket to update Kostas' awesome wiki p
I like getting the consistency in there.
I was never thinking of the intermediate data sets to be strictly produced
by a vertex, so I am unsure whether we should use that exact naming scheme,
or one that disconnects the results from the term "VertexResult".
On Tue, Mar 31, 2015 at 5:27 PM, Kostas
I like the fact that the naming scheme follows some logic.
I also like that we have two easy to understand concepts:
- Operator (be that in any of the above representations)
- Result (of executing an operator)
+1
On Tue, Mar 31, 2015 at 4:50 PM, Ufuk Celebi wrote:
> On a high level we call int
On a high level we call intermediate data produced by programs "intermediate
results". For example in a WordCount map-reduce program the map function
produces an intermediate result, which consists of (word, 1) pairs and the
reduce function consumes this intermediate result. Kostas has recently
13 matches
Mail list logo
