Kostas Tzoumas created FLINK-1893:
-
Summary: Add Scala support for Flink on Tez
Key: FLINK-1893
URL: https://issues.apache.org/jira/browse/FLINK-1893
Project: Flink
Issue Type: Improvement
Kostas Tzoumas created FLINK-1898:
-
Summary: Add support for self-joins to Flink on Tez
Key: FLINK-1898
URL: https://issues.apache.org/jira/browse/FLINK-1898
Project: Flink
Issue Type: Bug
I would also keep an eye on this issue from the Zeppelin project:
https://issues.apache.org/jira/browse/ZEPPELIN-44
The needed infrastructure is going to be very similar
On Thu, Apr 16, 2015 at 10:15 AM, Kostas Tzoumas ktzou...@apache.org
wrote:
Great, let us know if you run into any issues.
Great, let us know if you run into any issues.
Can you create a JIRA on the REPL and link to your repository for the
community to track the status?
On Wed, Apr 15, 2015 at 4:23 PM, Nikolaas s nikolaas.steenber...@gmail.com
wrote:
Thanks for the feedback guys!
Apparently The Scala Shell
Kostas Tzoumas created FLINK-1897:
-
Summary: Add accummulators and counters feature to Flink on Tez
Key: FLINK-1897
URL: https://issues.apache.org/jira/browse/FLINK-1897
Project: Flink
Issue
Kostas Tzoumas created FLINK-1895:
-
Summary: Add task chaining to Flink on Tez
Key: FLINK-1895
URL: https://issues.apache.org/jira/browse/FLINK-1895
Project: Flink
Issue Type: Improvement
Kostas Tzoumas created FLINK-1894:
-
Summary: Add Tez execution mode to Flink command-line tools
Key: FLINK-1894
URL: https://issues.apache.org/jira/browse/FLINK-1894
Project: Flink
Issue
Hi,
I want to join two tables in the following way:
case class WeightedEdge(src: Int, target: Int, weight: Double)
case class Community(communityID: Int, nodeID: Int)
case class CommunitySumTotal(communityID: Int, sumTotal: Double)
val communities: DataSet[Community]
val weightedEdges:
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
Felix Neutatz created FLINK-1899:
Summary: Table API Bug
Key: FLINK-1899
URL: https://issues.apache.org/jira/browse/FLINK-1899
Project: Flink
Issue Type: Bug
Components: Expression
Timo Walther created FLINK-1900:
---
Summary: Table API documentation example does not work
Key: FLINK-1900
URL: https://issues.apache.org/jira/browse/FLINK-1900
Project: Flink
Issue Type: Bug
As far as I see in [1], Peter's/Gyula's suggestion is what Infosphere
Streams does: symmetric hash join.
From [1]:
When a tuple is received on an input port, it is inserted into the window
corresponding to the input port, which causes the window to trigger. As
part of the trigger processing, 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
Theodore Vasiloudis created FLINK-1901:
--
Summary: Create sample operator for Dataset
Key: FLINK-1901
URL: https://issues.apache.org/jira/browse/FLINK-1901
Project: Flink
Issue Type:
Hello Gabor,
Yes, currently updateVertex only gets called when a new message was
received.
Could you please describe the logic behind your triangle count? The one I
know is described at the beginning of page 1643 in this article:
http://www.cc.gatech.edu/~bader/papers/GraphBSPonXMT-MTAAP2013.pdf
16 matches
Mail list logo