[jira] [Created] (CALCITE-4955) Release Calcite 1.29.0
Rui Wang created CALCITE-4955: - Summary: Release Calcite 1.29.0 Key: CALCITE-4955 URL: https://issues.apache.org/jira/browse/CALCITE-4955 Project: Calcite Issue Type: Task Reporter: Rui Wang Assignee: Rui Wang -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4269) Improvement on enumerable implementation for HOP and SESSION
Rui Wang created CALCITE-4269: - Summary: Improvement on enumerable implementation for HOP and SESSION Key: CALCITE-4269 URL: https://issues.apache.org/jira/browse/CALCITE-4269 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang 1. Should replace LinkedList with ArrayDeque because ArrayDeque should be more efficient in most cases. 2. list member variable should be final -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4176) Key descriptor can be optional in SESSION table function
Rui Wang created CALCITE-4176: - Summary: Key descriptor can be optional in SESSION table function Key: CALCITE-4176 URL: https://issues.apache.org/jira/browse/CALCITE-4176 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4164) Create a Spec doc for EMIT syntax
Rui Wang created CALCITE-4164: - Summary: Create a Spec doc for EMIT syntax Key: CALCITE-4164 URL: https://issues.apache.org/jira/browse/CALCITE-4164 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang Basically have a spec doc to introduce EMIT from SQL language/relation algebra perspective. This is very important because EMIT syntax is non-standard (maybe not yet) so it becomes an extension that Calcite introduces. The format might be as strict and detailed as what SQL standard does, but at least in should include: 1. new SQL syntax 2. new SQL keywords 3. The scope of EMIT clause (might not be needed as we won't allow column appear in EMIT clause) 4. All EMIT strategies 5. How does EMIT strategies propagate through the plan. For 5 my current thought it is EMIT will just affect FROM clause. For non-stream case it just means data emit all at once (e.g. EMIT AFTER WATERMARK). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4153) Implement EMIT AFTER WATERMARK
Rui Wang created CALCITE-4153: - Summary: Implement EMIT AFTER WATERMARK Key: CALCITE-4153 URL: https://issues.apache.org/jira/browse/CALCITE-4153 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4146) Implement EMIT AFTER WATERMARK
Rui Wang created CALCITE-4146:
-
Summary: Implement EMIT AFTER WATERMARK
Key: CALCITE-4146
URL: https://issues.apache.org/jira/browse/CALCITE-4146
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
Assignee: Rui Wang
The goal is to support the following syntax
{code:sql}
SELECT clause
FROM TUMBLE/HOP/SESSION
EMIT AFTER WATERMARK
{code}
note that "EMIT AFTER WATERMARK" is the new thing.
"EMIT AFTER WATERMARK" is proposed in [1]. This idea proposes a way to allow
streaming SQL queries control materialization latency. More specifically, it
means emit elements in a window once the watermark passes the end of that
window.
There are more context discussed in [2][3].
[1]: https://arxiv.org/pdf/1905.12133.pdf
[2]:
https://issues.apache.org/jira/browse/CALCITE-3272?focusedCommentId=17166580=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17166580
[3]:https://lists.apache.org/thread.html/r5bd9a6f7af2c0cd81aecd4de512fd889fbf15f112cc3704f188b1d4f%40%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4057) Implement trait propagation for EnumerableBatchNestedLoopJoin
Rui Wang created CALCITE-4057: - Summary: Implement trait propagation for EnumerableBatchNestedLoopJoin Key: CALCITE-4057 URL: https://issues.apache.org/jira/browse/CALCITE-4057 Project: Calcite Issue Type: Task Reporter: Rui Wang Assignee: Rui Wang EnumerableBatchNestedLoopJoin can has the same way to propagate traits, just like EnumerableNestedLoopJoin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4052) Enable Top-down Optimization
Rui Wang created CALCITE-4052: - Summary: Enable Top-down Optimization Key: CALCITE-4052 URL: https://issues.apache.org/jira/browse/CALCITE-4052 Project: Calcite Issue Type: Task Reporter: Rui Wang We can enable top-down opt globally by updating saffron.properties. Some tests will fail because top-down opt changes the output plan. The easiest way is to update those tests to make them match the output plan produced after top-down opt. Alternatively, we might change testing framework to verify two output plans: one for top-down opt, another for when top-down opt not enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4051) TVF Session Optimizations
Rui Wang created CALCITE-4051: - Summary: TVF Session Optimizations Key: CALCITE-4051 URL: https://issues.apache.org/jira/browse/CALCITE-4051 Project: Calcite Issue Type: Improvement Reporter: Rui Wang Current TVF Session has the following limitation: Use a "dummy" key to go through a GBK to compute window_start and window_end. This introduces an extra shuffle so it costs more. One optimizations we can do is always merge TableFunctionScanRel with AggregationRel, thus we can use only one GBK to compute both SESSION window_start and window_end, and aggregations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4033) SqlNode.toSqlString generates wrong query for syntax "literal(select * from unnest(...))"
Rui Wang created CALCITE-4033:
-
Summary: SqlNode.toSqlString generates wrong query for syntax
"literal(select * from unnest(...))"
Key: CALCITE-4033
URL: https://issues.apache.org/jira/browse/CALCITE-4033
Project: Calcite
Issue Type: Bug
Reporter: Rui Wang
Reported from: https://issues.apache.org/jira/browse/DRILL-7722
If use this query
{code:sql}
SELECT
item.name,
relations.*
FROM dfs.tmp item
JOIN LATERAL(
SELECT * FROM UNNEST(item.related) i(rels)
) relations
ON TRUE
{code}
Then SqlNode.toSqlString() generates
{code:sql}
SELECT
item.name,
relations.*
FROM dfs.tmp item
JOIN LATERAL(
SELECT * FROM (UNNEST(item.related)) i(rels)
) relation
ON TRUE").ok("SELECT `ITEM`.`NAME`, `RELATIONS`.*
FROM `DFS`.`TMP` AS `ITEM`
INNER JOIN LATERAL (SELECT *
FROM (UNNEST(`ITEM`.`RELATED`)) AS `I` (`RELS`)) AS `RELATIONS` ON TRUE");
{code}
Note that there are extra parentheses around the UNNEST, and make the generated
query unparsable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4030) Assert error during top-down optimization with Project/Filter Traits passdown and derivation
Rui Wang created CALCITE-4030:
-
Summary: Assert error during top-down optimization with
Project/Filter Traits passdown and derivation
Key: CALCITE-4030
URL: https://issues.apache.org/jira/browse/CALCITE-4030
Project: Calcite
Issue Type: Task
Reporter: Rui Wang
For example, with https://github.com/apache/calcite/pull/1985, and enable
top-down opt by set "calcite.planner.topdown.opt=true" in saffron.properties,
run test case SortRemoveRuleTest.removeSortOverEnumerableHashJoin, we can see:
{code:java}
java.lang.AssertionError
at
org.apache.calcite.plan.volcano.OptimizeTask$RelNodeOptTask.execute(OptimizeTask.java:232)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:553)
at
org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:327)
at
org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:362)
at
org.apache.calcite.rel.rules.SortRemoveRuleTest.transform(SortRemoveRuleTest.java:77)
at
org.apache.calcite.rel.rules.SortRemoveRuleTest.removeSortOverEnumerableHashJoin(SortRemoveRuleTest.java:102)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4021) EnumerableUnion should preserve ordering when all inputs have the same collation
Rui Wang created CALCITE-4021:
-
Summary: EnumerableUnion should preserve ordering when all inputs
have the same collation
Key: CALCITE-4021
URL: https://issues.apache.org/jira/browse/CALCITE-4021
Project: Calcite
Issue Type: Improvement
Reporter: Rui Wang
For query:
"select name from sales_dept
union
select name from it_dept
order by mgr"
We could generate a plan based on
https://issues.apache.org/jira/browse/CALCITE-4017:
{code:java}
EnumerableUnion
EnumerableProject
EnumerableSort
EnumerableTableScan[name="sales_dept"]
EnumerableProject
EnumerableSort
EnumerableTableScan[name="it_dept"]
{code}
So EnumerableUnion should preserve ordering when all input have the same
collation to make sure result of query is correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4000) Support the offset parameters for TUMBLE/HOP/SESSION table functions
Rui Wang created CALCITE-4000: - Summary: Support the offset parameters for TUMBLE/HOP/SESSION table functions Key: CALCITE-4000 URL: https://issues.apache.org/jira/browse/CALCITE-4000 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang TUMBLE/HOP/SESSION have an optional "OFFSET" parameter to indicate how many time off from 0 for windowing. TUMBLE(table, size [, offset]) HOP(table, shift, size, [, offset]) SESSION(table, gap, [, offset]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3992) Beam ZetaSQL supports pure SQL user-defined aggregation functions
Rui Wang created CALCITE-3992: - Summary: Beam ZetaSQL supports pure SQL user-defined aggregation functions Key: CALCITE-3992 URL: https://issues.apache.org/jira/browse/CALCITE-3992 Project: Calcite Issue Type: Task Reporter: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3985) Simplify grouped window function in parser
Rui Wang created CALCITE-3985:
-
Summary: Simplify grouped window function in parser
Key: CALCITE-3985
URL: https://issues.apache.org/jira/browse/CALCITE-3985
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
Currently in parser, there is [1]:
{code:java}
SqlCall GroupByWindowingCall():
{
final Span s;
final List args;
final SqlOperator op;
}
{
(
{
s = span();
op = SqlStdOperatorTable.TUMBLE_OLD;
}
|
{
s = span();
op = SqlStdOperatorTable.HOP_OLD;
}
|
{
s = span();
op = SqlStdOperatorTable.SESSION_OLD;
}
)
args = UnquantifiedFunctionParameterList(ExprContext.ACCEPT_SUB_QUERY) {
return op.createCall(s.end(this), args);
}
}
{code}
The s=span() are duplicates and there could be a way to keep only one s=span().
[1]:
https://github.com/apache/calcite/blob/master/core/src/main/codegen/templates/Parser.jj#L6049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3964) Support in DESCRIPTOR operator
Rui Wang created CALCITE-3964:
-
Summary: Support in DESCRIPTOR operator
Key: CALCITE-3964
URL: https://issues.apache.org/jira/browse/CALCITE-3964
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
Assignee: Rui Wang
>From SQL standard 2016
{code:sql}
8.15
::=
::=
DESCRIPTOR
::=
[ { }... ]
::=
[ ]
A is the keyword DESCRIPTOR followed by a parenthesized
list of column names; each column name may optionally have a data type. If
every column name has a data type, then the descriptor describes a row type. In
the examples, CSVreader and Pivot use descriptor arguments that are just lists
of column names; ExecR is an example that uses a descriptor to pass a complete
row type.
{code}
DESCRIPTOR can include an optional data type, which will enable type checking
in SQL validator. It is useful for streaming windowing: the windowing is
required to be applied on TIMESTAMP type, and we can rely on descriptor to do
type validation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3945) Update Streaming documentation
Rui Wang created CALCITE-3945: - Summary: Update Streaming documentation Key: CALCITE-3945 URL: https://issues.apache.org/jira/browse/CALCITE-3945 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3796) Support Array operator <, <=, >, >=
Rui Wang created CALCITE-3796: - Summary: Support Array operator <, <=, >, >= Key: CALCITE-3796 URL: https://issues.apache.org/jira/browse/CALCITE-3796 Project: Calcite Issue Type: Improvement Reporter: Rui Wang Assignee: Rui Wang Seems like Calcite has an =, <> support for array type. But it does not have <, <=, >, >= support. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3780) SESSION Table-valued Function
Rui Wang created CALCITE-3780: - Summary: SESSION Table-valued Function Key: CALCITE-3780 URL: https://issues.apache.org/jira/browse/CALCITE-3780 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang We can create SESSION table-valued function to replace GROUP BY SESSION for inactive gap session functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3776) Create a task in Gradle to run JdbcExample
Rui Wang created CALCITE-3776: - Summary: Create a task in Gradle to run JdbcExample Key: CALCITE-3776 URL: https://issues.apache.org/jira/browse/CALCITE-3776 Project: Calcite Issue Type: Task Reporter: Rui Wang Got some troubles to run main class "org.apache.calcite.examples.foodmart.java.JdbcExample": 1. Intellij cannot run it directly. 2. "java -cp" style commands was not easy to run: 1) ended up with a "Class Not Found" situation while jar should be added to classpath already. 2) "java -cp" need add more jars to classpath (e.g. lingq4j, avatica, etc.) So I proposal to create a gradle task to run "JdbcExample". It will be as easy as running "./gradlew :core:runJdbcExample". Intellij can also be easily configured to run this command thus using debugger in IDE becomes possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3743) Support PERCENT_RANK window aggregate function
Rui Wang created CALCITE-3743: - Summary: Support PERCENT_RANK window aggregate function Key: CALCITE-3743 URL: https://issues.apache.org/jira/browse/CALCITE-3743 Project: Calcite Issue Type: Task Reporter: Rui Wang Assignee: Rui Wang It seems like Calcite does not have an implementation of PERCENT_RANK: see the list of implemented window aggregate function: https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635 Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The definition is consistent: the function returns relative rank of the current row: (rank - 1) / (total partition rows - 1) The return value should be double. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3737) HOP Table-valued Function
Rui Wang created CALCITE-3737: - Summary: HOP Table-valued Function Key: CALCITE-3737 URL: https://issues.apache.org/jira/browse/CALCITE-3737 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3638) Reduce ambiguous hint strategies
Rui Wang created CALCITE-3638: - Summary: Reduce ambiguous hint strategies Key: CALCITE-3638 URL: https://issues.apache.org/jira/browse/CALCITE-3638 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT /*hints*/. Also, hints are designed to be propagable such that the top SELECT hints can be propagated to other hintable nodes. For some hint strategies like resource, there will be ambiguity because we allow it be applicate to more than one type of node (e.g. resource works for both project and aggregate). So we could: 1. want to set resources for project 2. want to set resources for aggregate 3. want to set resources for project and aggregate, but have different parameters. There are two alternatives: 1. don't limit hint syntax to the top select. Allow it be put near, e.g. aggregation, etc. 2. have different names for the resource hint. e.g. project_resources, aggregate_resources, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3629) Table-valued function implementor interface
Rui Wang created CALCITE-3629:
-
Summary: Table-valued function implementor interface
Key: CALCITE-3629
URL: https://issues.apache.org/jira/browse/CALCITE-3629
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
The current implementation of TUMBLE is the following:
{code:java}
if (isTumble()) {
// create expressions and blockstatement
} else {
// other table function scan enumerable implementation.
}
{code}
This style is less extensible. We will add more builtin table-valued function
implementation and we shouldn't add more if-else with complicated
implementation.
A better practice is in RexImpTable, each operator register its implementor,
and then the code will be becomes:
{code:java}
if (implementor defined) {
return implementor.implement(...)
} else {
// default table function scan enumerable implementation for those that does
not have implementor.
}
{code}
The current implementor[1] is not enough for table-valued function as
table-valued function need both inputPhysType and outPhysType, and potential
other params to implement itself.
Another condition is we might need more table-valued function implementations
to abstract a common interface.
[1]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/CallImplementor.java#L38
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3619) Support TIMESTAMP_WITH_TIME_ZONE in CAST
Rui Wang created CALCITE-3619: - Summary: Support TIMESTAMP_WITH_TIME_ZONE in CAST Key: CALCITE-3619 URL: https://issues.apache.org/jira/browse/CALCITE-3619 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Should figure out the CAST relationship between TIMESTAMP_WITH_TIME_ZONE and other types, and add the support accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3594) Support Hot Groupby keys hint
Rui Wang created CALCITE-3594:
-
Summary: Support Hot Groupby keys hint
Key: CALCITE-3594
URL: https://issues.apache.org/jira/browse/CALCITE-3594
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
Assignee: Rui Wang
It will be useful for Apache Beam if we support the following SqlHint:
SELECT * FROM t
GROUP BY t.key_column /* + hot_key(key1=fanout_factor, key2=fanout_factor) */)
The hot key strategy works on aggregation and it provides a list of hot keys
with fanout factor for a column. The fanout factor says how many partition
should be created for that specific key, such that we can have a per partition
aggregate and then have a final aggregate. One example to explain it:
SELECT * FROM t
GROUP BY t.key_column /* + hot_key("value1"=2) */)
// for the key_column, there is a "value1" which appear so many times (so it's
hot), please consider split it into two partition and process separately.
Such problem is common for big data processing, where hot key creates slowest
machine which either slow down the whole pipeline or make retries. In such
case, one common resolution is to split data to multiple partition and
aggregate per partition, and then have a final combine.
Usually execution engine won't know what is the hot key(s). SqlHint provides a
good way to tell the engine which key is useful to deal with it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3582) Make StructFlatterner configurable in PlannerImpl
Rui Wang created CALCITE-3582: - Summary: Make StructFlatterner configurable in PlannerImpl Key: CALCITE-3582 URL: https://issues.apache.org/jira/browse/CALCITE-3582 Project: Calcite Issue Type: Task Reporter: Rui Wang Assignee: Rui Wang There is a use case where users want to mix Beam programming model with Beam SQL together to process a dataset. The following is an example of the use case: dataset.apply(something user defined) .apply(SELECT ...) .apply(something user defined) As you can see, after the SQL statement is applied, the data structure should be preserved for further processing. Make struct flattener configurable in PlannerImpl to allow disabling it when not needed can be a solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3577) Interval unparsing to BigQuery syntax is not correct.
Rui Wang created CALCITE-3577: - Summary: Interval unparsing to BigQuery syntax is not correct. Key: CALCITE-3577 URL: https://issues.apache.org/jira/browse/CALCITE-3577 Project: Calcite Issue Type: Bug Reporter: Rui Wang Assignee: Rui Wang Fix For: 1.22.0 BQ does not support range time unit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3548) ./gradlew :ubenchmark:jmh cannot find benchmark to run
Rui Wang created CALCITE-3548: - Summary: ./gradlew :ubenchmark:jmh cannot find benchmark to run Key: CALCITE-3548 URL: https://issues.apache.org/jira/browse/CALCITE-3548 Project: Calcite Issue Type: Bug Components: build Reporter: Rui Wang Assignee: Rui Wang Per https://github.com/melix/jmh-gradle-plugin#configuration, jmh-gradle-plugin expects a file structure as: src/jmh/java, but current structure is src/main/jmh, thus ./gradlew :ubenchmark:jmh reports no benchmark to run. Change the structure accordingly fixed this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3509) Watermark Propagation
Rui Wang created CALCITE-3509: - Summary: Watermark Propagation Key: CALCITE-3509 URL: https://issues.apache.org/jira/browse/CALCITE-3509 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang To have a useful enumerable implementation for streaming windowing semantic in Calcite, and also make Emit syntax useful, we will need to introduce watermark into Calcite. More specifically, the following should be discussed: 1. How is watermark generated? What changes are required on source/table scan? 2. How does watermark propagate through the whole plan? 3. Where watermark is used to control the time to emit data? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3501) EnumerableTableFunctionScan's implement() is not correct
Rui Wang created CALCITE-3501: - Summary: EnumerableTableFunctionScan's implement() is not correct Key: CALCITE-3501 URL: https://issues.apache.org/jira/browse/CALCITE-3501 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang EnumerableTableFunctionScan's implement() should have an implementation which generates code that iterates input, calls the RexCall and generates output (can refer to the implementation of EnumerableCalc). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3499) EnumerableTableFunctionScanRule doesn't convert its inputs to Enumerable.CONVENTION
Rui Wang created CALCITE-3499:
-
Summary: EnumerableTableFunctionScanRule doesn't convert its
inputs to Enumerable.CONVENTION
Key: CALCITE-3499
URL: https://issues.apache.org/jira/browse/CALCITE-3499
Project: Calcite
Issue Type: Bug
Reporter: Rui Wang
Assignee: Rui Wang
The fix is trival: use convertList to convert inputs to Enumerable.CONVENTION.
> Graphviz:
> digraph G {
> root [style=filled,label="Root"];
> subgraph cluster0{
> label="Set 0 RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID,
> VARCHAR(10) PRODUCT, INTEGER UNITS)";
> rel2 [label="rel#2:LogicalTableScan\ntable=[ORINOCO,
> ORDERS]\nrows=100.0, cost={inf}",shape=box]
> rel15
> [label="rel#15:LogicalProject\ninput=RelSubset#14,ROWTIME=$0,ID=$1,PRODUCT=$2,UNITS=$3\nrows=100.0,
> cost={inf}",shape=box]
> rel30
> [label="rel#30:EnumerableProject\ninput=RelSubset#29,ROWTIME=$0,ID=$1,PRODUCT=$2,UNITS=$3\nrows=100.0,
> cost={151.0 rows, 451.01 cpu, 0.0 io}",shape=box]
> rel32 [label="rel#32:BindableTableScan\ntable=[ORINOCO,
> ORDERS]\nrows=100.0, cost={1.0 rows, 1.01 cpu, 0.0 io}",color=blue,shape=box]
> rel34 [label="rel#34:EnumerableTableScan\ntable=[ORINOCO,
> ORDERS]\nrows=100.0, cost={100.0 rows, 101.0 cpu, 0.0 io}",shape=box]
> rel35
> [label="rel#35:EnumerableInterpreter\ninput=RelSubset#33\nrows=100.0,
> cost={51.0 rows, 51.01 cpu, 0.0 io}",color=blue,shape=box]
> subset14 [label="rel#14:Subset#0.NONE.[0]"]
> subset29 [label="rel#29:Subset#0.ENUMERABLE.[0]"]
> subset33 [label="rel#33:Subset#0.BINDABLE.[0]"]
> }
> subgraph cluster2{
> label="Set 2 RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID,
> VARCHAR(10) PRODUCT, INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)";
> rel17
> [label="rel#17:LogicalTableFunctionScan\ninput#0=RelSubset#14,invocation=TUMBLE($3,
> 'ROWTIME', 6:INTERVAL MINUTE),rowType=RecordType(TIMESTAMP(0) ROWTIME,
> INTEGER ID, VARCHAR(10) PRODUCT, INTEGER UNITS, TIMESTAMP(0) wstart,
> TIMESTAMP(0) wend)\nrows=100.0, cost={inf}",shape=box]
> rel19
> [label="rel#19:LogicalProject\ninput=RelSubset#18,ROWTIME=$0,ID=$1,PRODUCT=$2,UNITS=$3,wstart=$4,wend=$5\nrows=100.0,
> cost={inf}",shape=box]
> rel25
> [label="rel#25:AbstractConverter\ninput=RelSubset#18,convention=ENUMERABLE,sort=[]\nrows=100.0,
> cost={inf}",shape=box]
> rel27
> [label="rel#27:EnumerableProject\ninput=RelSubset#26,ROWTIME=$0,ID=$1,PRODUCT=$2,UNITS=$3,wstart=$4,wend=$5\nrows=100.0,
> cost={inf}",shape=box]
> rel28
> [label="rel#28:EnumerableTableFunctionScan\ninput#0=RelSubset#14,invocation=TUMBLE($3,
> 'ROWTIME', 6:INTERVAL MINUTE),rowType=RecordType(TIMESTAMP(0) ROWTIME,
> INTEGER ID, VARCHAR(10) PRODUCT, INTEGER UNITS, TIMESTAMP(0) wstart,
> TIMESTAMP(0) wend)\nrows=100.0, cost={inf}",shape=box]
> subset18 [label="rel#18:Subset#2.NONE.[]"]
> subset26 [label="rel#26:Subset#2.ENUMERABLE.[]"]
> }
> root -> subset26;
> subset14 -> rel2;
> subset14 -> rel15; rel15 -> subset14;
> subset29 -> rel30; rel30 -> subset29;
> subset33 -> rel32[color=blue];
> subset29 -> rel34;
> subset29 -> rel35[color=blue]; rel35 -> subset33[color=blue];
> subset18 -> rel17; rel17 -> subset14;
> subset18 -> rel19; rel19 -> subset18;
> subset26 -> rel25; rel25 -> subset18;
> subset26 -> rel27; rel27 -> subset26;
> subset26 -> rel28; rel28 -> subset14;
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3418) Grouped Window Function "$TUMBLE" should return "
Rui Wang created CALCITE-3418: - Summary: Grouped Window Function "$TUMBLE" should return " Key: CALCITE-3418 URL: https://issues.apache.org/jira/browse/CALCITE-3418 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3382) Rename current TUMBLE to "TUMBLE_OLD" and add TUMBLE to Parser
Rui Wang created CALCITE-3382: - Summary: Rename current TUMBLE to "TUMBLE_OLD" and add TUMBLE to Parser Key: CALCITE-3382 URL: https://issues.apache.org/jira/browse/CALCITE-3382 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang Per discussion in https://github.com/apache/calcite/pull/1457, we should add TUMBLE to parser and rename it to "TUMBLE_OLD". "TUMBLE" as an operator name will be left for table-value function TUMBLE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3343) Improve LogicalTableFunctionScan to match table function windowing
Rui Wang created CALCITE-3343:
-
Summary: Improve LogicalTableFunctionScan to match table function
windowing
Key: CALCITE-3343
URL: https://issues.apache.org/jira/browse/CALCITE-3343
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
Assignee: Rui Wang
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/logical/LogicalTableFunctionScan.java#L40
{code:java}
/**
* Creates a LogicalTableFunctionScan.
*
* @param clusterCluster that this relational expression belongs to
* @param inputs 0 or more relational inputs
* @param traitSet Trait set
* @param rexCallFunction invocation expression
* @param elementTypeElement type of the collection that will implement
* this table
* @param rowTypeRow type produced by function
* @param columnMappings Column mappings associated with this function
*/
public LogicalTableFunctionScan(
RelOptCluster cluster,
RelTraitSet traitSet,
List inputs,
RexNode rexCall,
Type elementType,
RelDataType rowType,
Set columnMappings) {
super(cluster, traitSet, inputs, rexCall, elementType, rowType,
columnMappings);
}
{code}
There might be a gap to make LogicalTableFunctionScan work for table function
windowing:
1. we need a RexInputRef parameter (converted from the DESCRIPTOR) to mark
which column is the watermarked column.
2. we need a List of RexNode(RexLiteral) for interval parameters.
The most straightforward approach while maintaining backward compatible, seems
is add another constructor with an additional List parameter. We could
save RexInputRef and internals (RexLiteral) to this parameter.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
Rui Wang created CALCITE-3340: - Summary: Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator Key: CALCITE-3340 URL: https://issues.apache.org/jira/browse/CALCITE-3340 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang For query: SELECT * FROM TABLE(TUMBLE( TABLE ORDERS, DESCRIPTOR(ROWTIME), INTERVAL '10' MINUTE)) (note reuse TUMBLE operator than use a new unresolved one) Calcite validator will does a step to do registration and "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] again but there is no matching Sqlkind handling for "TUMBLE" (note that TUMBLE's node kind is TUMBLE). It seems we should support TUMBLE in [2]. The details of how to support it needs a bit more discussion. [1]: https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3339) DESCRIPTOR as a SQL operator in SqlStdOperatorTable
Rui Wang created CALCITE-3339: - Summary: DESCRIPTOR as a SQL operator in SqlStdOperatorTable Key: CALCITE-3339 URL: https://issues.apache.org/jira/browse/CALCITE-3339 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang For query: SELECT * FROM TABLE(TUMBLE_TVF( TABLE ORDERS, // or could be TABLE(ORDERS) DESCRIPTOR(ROWTIME), INTERVAL '10' MINUTE)) TABLE ORDERS is converted to SqlPrefixOperator, but DESCRIPTOR(ROWTIME) has no mapping in SqlStdOperatorTable. There are two options: 1. There is a SqlColumnListConstructor which serves the same(similar) purpose to specific a list of column. 2. We create a new operator for DESCRIPTOR. Reuse existing code is always good so we can start from option one and see if it works. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3272) TUMBLE Table Value Function
Rui Wang created CALCITE-3272: - Summary: TUMBLE Table Value Function Key: CALCITE-3272 URL: https://issues.apache.org/jira/browse/CALCITE-3272 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Define a builtin TVF: Tumble (data , timecol , dur, [ offset ]) The return value of Tumble is a relation that includes all columns of data as well as additional event time columns wstart and wend. Examples of TUMBLE TVF are (from https://s.apache.org/streaming-beam-sql): 8:21> SELECT * FROM Bid; -- | bidtime | price | item | -- | 8:07| $2| A| | 8:11| $3| B| | 8:05| $4| C| | 8:09| $5| D| | 8:13| $1| E| | 8:17| $6| F| -- 8:21> SELECT * FROM Tumble ( data=> TABLE Bid , timecol => DESCRIPTOR ( bidtime ) , dur => INTERVAL '10' MINUTES , offset => INTERVAL '0' MINUTES ); -- | wstart | wend | bidtime | price | item | -- | 8:00 | 8:10 | 8:07| $2| A| | 8:10 | 8:20 | 8:11| $3| B| | 8:00 | 8:10 | 8:05| $4| C| | 8:00 | 8:10 | 8:09| $5| D| | 8:10 | 8:20 | 8:13| $1| E| | 8:10 | 8:20 | 8:17| $6| F| -- 8:21> SELECT MAX ( wstart ) , wend , SUM ( price ) FROM Tumble ( data=> TABLE ( Bid ) , timecol => DESCRIPTOR ( bidtime ) , dur => INTERVAL '10 ' MINUTES ) GROUP BY wend; - | wstart | wend | price | - | 8:00 | 8:10 | $11 | | 8:10 | 8:20 | $10 | - -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-2889) EnumUtils's from internal cannot handle function with array type
Rui Wang created CALCITE-2889: - Summary: EnumUtils's from internal cannot handle function with array type Key: CALCITE-2889 URL: https://issues.apache.org/jira/browse/CALCITE-2889 Project: Calcite Issue Type: Bug Components: core Reporter: Rui Wang https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumUtils.java#L212 If "targetTypes" is from "method.getParameterTypes()" and if method's signature is "func(stirng ... args)", then "targetTypes" will contain one type "String[].class", but "expressions" could contain one than one element, so it throws IndexOutOfBoundException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2645) SESSION_END() is transformed to RexInputRef, which is always equal to SESSION_START()
Rui Wang created CALCITE-2645: - Summary: SESSION_END() is transformed to RexInputRef, which is always equal to SESSION_START() Key: CALCITE-2645 URL: https://issues.apache.org/jira/browse/CALCITE-2645 Project: Calcite Issue Type: Bug Reporter: Rui Wang Assignee: Julian Hyde https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/AuxiliaryConverter.java#L57 In the AuxiliaryConverter implementation, SESSION_END() is transformed to a RexInputRef, as the same as SESSION_START(). By doing so, it cannot restored when generating physical plan because which RexInputRef is start, and which RexInputRef is end cannot be differentiated. Ideally, during toRel, SESSION_END can be kept as a RexCall with function information in it. So in the following step, the RexCall can be replaced as a input reference. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2517) INSERT INTO a table with Row column type
Rui Wang created CALCITE-2517:
-
Summary: INSERT INTO a table with Row column type
Key: CALCITE-2517
URL: https://issues.apache.org/jira/browse/CALCITE-2517
Project: Calcite
Issue Type: Bug
Reporter: Rui Wang
Assignee: Julian Hyde
When run this query:
{code:java}
CREATE TABLE table_test (payload ROW);
INSERT INTO table_test SELECT ROW(1, '2');
{code}
I have the following exception:
{code:java}
Error: Error while executing SQL "INSERT INTO table_test SELECT ROW(1, '2')":
From line 1, column 31 to line 1, column 41: Cannot assign to target field
'payload' of type RecordType(INTEGER id, VARCHAR name) from source field
'EXPR$0' of type RecordType(INTEGER EXPR$0, CHAR(1) EXPR$1) (state=,code=0)
java.sql.SQLException: Error while executing SQL "INSERT INTO table_test SELECT
ROW(1, '2')": From line 1, column 31 to line 1, column 41: Cannot assign to
target field 'payload' of type RecordType(INTEGER id, VARCHAR name) from source
field 'EXPR$0' of type RecordType(INTEGER EXPR$0, CHAR(1) EXPR$1) at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:217)
at sqlline.Commands.execute(Commands.java:823) at
sqlline.Commands.sql(Commands.java:733) at
sqlline.SqlLine.dispatch(SqlLine.java:795) at
sqlline.SqlLine.begin(SqlLine.java:668) at
org.apache.beam.sdk.extensions.sql.jdbc.BeamSqlLine.runSqlLine(BeamSqlLine.java:75)
at
org.apache.beam.sdk.extensions.sql.jdbc.BeamSqlLine.main(BeamSqlLine.java:39)
Caused by:
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.runtime.CalciteContextException:
From line 1, column 31 to line 1, column 41: Cannot assign to target field
'payload' of type RecordType(INTEGER id, VARCHAR name) from source field
'EXPR$0' of type RecordType(INTEGER EXPR$0, CHAR(1) EXPR$1) at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:783)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4774)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:4476)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.validateInsert(SqlValidatorImpl.java:4236)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.SqlInsert.validate(SqlInsert.java:148)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:920)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:628)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:552)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:264)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
at
[jira] [Created] (CALCITE-2516) Struct's field name cannot be found
Rui Wang created CALCITE-2516:
-
Summary: Struct's field name cannot be found
Key: CALCITE-2516
URL: https://issues.apache.org/jira/browse/CALCITE-2516
Project: Calcite
Issue Type: Bug
Reporter: Rui Wang
Assignee: Julian Hyde
When run queries
{code:java}
SELECT a.row_col.EXPR$0 FROM (SELECT ROW('str', 'str', 'str') as row_col) as
a{code}
and
{code:java}
CREATE TABLE nestedRowTestTavble (
col ROW
)
SELECT a.col.nonRowfield1 FROM (SELECT col from nestedRowTestTable) as a
{code}
I am facing the exception:
{code:java}
-1
java.lang.ArrayIndexOutOfBoundsException: -1 at
java.util.ArrayList.elementData(ArrayList.java:423) at
java.util.ArrayList.get(ArrayList.java:436) at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SelectNamespace.getMonotonicity(SelectNamespace.java:80)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.SqlIdentifier.getMonotonicity(SqlIdentifier.java:379)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3843)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:664)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
at
org.apache.beam.sdk.extensions.sql.impl.BeamQueryPlanner.convertToBeamRel(BeamQueryPlanner.java:125)
at
org.apache.beam.sdk.extensions.sql.impl.BeamSqlEnv.parseQuery(BeamSqlEnv.java:105)
at
org.apache.beam.sdk.extensions.sql.BeamComplexTypeTest.testNestedRowConstructor(BeamComplexTypeTest.java:227)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:319)
at org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:319)
at org.junit.rules.RunRules.evaluate(RunRules.java:20) at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
[jira] [Created] (CALCITE-2515) Cannot SELECT ROW FROM ROW(single field)
Rui Wang created CALCITE-2515:
-
Summary: Cannot SELECT ROW FROM ROW(single field)
Key: CALCITE-2515
URL: https://issues.apache.org/jira/browse/CALCITE-2515
Project: Calcite
Issue Type: Bug
Reporter: Rui Wang
Assignee: Julian Hyde
When runs this query: `SELECT a.row_col FROM (SELECT ROW('str') as row_col) as
a`, there is
{code:java}
index (1) must be less than size (1) java.lang.IndexOutOfBoundsException: index
(1) must be less than size (1) at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1177)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1159)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.com.google.common.collect.SingletonImmutableList.get(SingletonImmutableList.java:41)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.type.InferTypes.lambda$static$1(InferTypes.java:80)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1803)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:349)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3797)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:664)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2065)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:1950)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:640)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
at
org.apache.beam.repackaged.beam_sdks_java_extensions_sql.org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
at
org.apache.beam.sdk.extensions.sql.impl.BeamQueryPlanner.convertToBeamRel(BeamQueryPlanner.java:125)
at
org.apache.beam.sdk.extensions.sql.impl.BeamSqlEnv.parseQuery(BeamSqlEnv.java:105)
at
org.apache.beam.sdk.extensions.sql.BeamComplexTypeTest.testNestedRowConstructor(BeamComplexTypeTest.java:226)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:319)
at org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:319)
at org.junit.rules.RunRules.evaluate(RunRules.java:20) at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
