[jira] [Created] (FLINK-15624) Pulsar Sink
Yijie Shen created FLINK-15624: -- Summary: Pulsar Sink Key: FLINK-15624 URL: https://issues.apache.org/jira/browse/FLINK-15624 Project: Flink Issue Type: Sub-task Reporter: Yijie Shen -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-15089) Pulsar Catalog
Yijie Shen created FLINK-15089: -- Summary: Pulsar Catalog Key: FLINK-15089 URL: https://issues.apache.org/jira/browse/FLINK-15089 Project: Flink Issue Type: Sub-task Components: Connectors / Common Reporter: Yijie Shen Per discussion in the mailing list, A Pulsar Catalog implementation is made to a single task. The design doc is: [https://docs.google.com/document/d/1LMnABtXn-wQedsmWv8hopvx-B-jbdr8-jHbIiDhdsoE/edit?usp=sharing] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-14146) Introduce Pulsar connector
Yijie Shen created FLINK-14146: -- Summary: Introduce Pulsar connector Key: FLINK-14146 URL: https://issues.apache.org/jira/browse/FLINK-14146 Project: Flink Issue Type: New Feature Reporter: Yijie Shen Please see FLIP-72 for detailed information: [https://cwiki.apache.org/confluence/display/FLINK/FLIP-72%3A+Introduce+Pulsar+Connector] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-3976) Alias fields of physical plan node to avoid name collision with Calcite protected fields
Yijie Shen created FLINK-3976:
-
Summary: Alias fields of physical plan node to avoid name
collision with Calcite protected fields
Key: FLINK-3976
URL: https://issues.apache.org/jira/browse/FLINK-3976
Project: Flink
Issue Type: Improvement
Components: Table API
Reporter: Yijie Shen
Priority: Minor
The field name collisions in physical plan node make IDE hard to get a field's
type and unable to give accurate hint while developing, I suggest we rename
them :)
The collisions are: {{rowType}}, {{input}}, {{table}}, {{left}}, {{right}},
{{tuples}},
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLINK-3754) Add a validation phase before construct RelNode using TableAPI
Yijie Shen created FLINK-3754: - Summary: Add a validation phase before construct RelNode using TableAPI Key: FLINK-3754 URL: https://issues.apache.org/jira/browse/FLINK-3754 Project: Flink Issue Type: Improvement Components: Table API Affects Versions: 1.0.0 Reporter: Yijie Shen Assignee: Yijie Shen Unlike sql string's execution, which have a separate validation phase before RelNode construction, Table API lacks the counterparts and the validation is scattered in many places. I suggest to add a single validation phase and detect problems as early as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLINK-3736) Move toRexNode and toAggCall logic into Expressions
Yijie Shen created FLINK-3736: - Summary: Move toRexNode and toAggCall logic into Expressions Key: FLINK-3736 URL: https://issues.apache.org/jira/browse/FLINK-3736 Project: Flink Issue Type: Improvement Components: Table API Reporter: Yijie Shen Priority: Minor Since we have a one-to-one mapping from Flink Expression to Calcite RexNode, and we will implement more and more expressions to make flink-table a full-fledged module, I think it's worthwhile to let each Expression take care of its own behaviour on conversion to RexNode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLINK-3723) Aggregate Functions and scalar expressions shouldn't be mixed in select
Yijie Shen created FLINK-3723:
-
Summary: Aggregate Functions and scalar expressions shouldn't be
mixed in select
Key: FLINK-3723
URL: https://issues.apache.org/jira/browse/FLINK-3723
Project: Flink
Issue Type: Improvement
Components: Table API
Affects Versions: 1.0.1
Reporter: Yijie Shen
When we type {code}select deptno, name, max(age) from dept group by
deptno;{code} in calcite or Oracle, it will complain {code}Expression 'NAME' is
not being grouped{code} or {code}Column 'dept.name' is invalid in the select
list because it is not contained in either an aggregate function or the GROUP
BY clause.{code} because of the nondeterministic result.
Therefore, I suggest to separate the current functionality of `select` into two
api, the new `select` only handle scalar expressions, and an `agg` accept
Aggregates.
{code}
def select(exprs: Expression*)
def agg(aggs: Aggregation*)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
