[
https://issues.apache.org/jira/browse/CALCITE-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiejiajun updated CALCITE-4665:
-------------------------------
Description:
UT:
{code:java}
builder.scan("EMP")
.aggregate(builder.groupKey(0, 1, 7),
builder.aggregateCall(SqlStdOperatorTable.COUNT,
builder.field("JOB")).as("job_num"))
.aggregate(
builder.groupKey(ImmutableBitSet.of(0, 1, 2),
(Iterable<ImmutableBitSet>)
ImmutableList.of(ImmutableBitSet.of(0, 1))))
// GROUP BY 0,1,2 GROUPING SETS((0, 1))
.build();
{code}
Before I fixed it, you can see groupings set are missing because LogicalProject.
{code:java}
LogicalProject(EMPNO=[$0], ENAME=[$1], DEPTNO=[$2])
LogicalAggregate(group=[{0, 1, 7}], job_num=[COUNT($2)])
LogicalTableScan(table=[[scott, EMP]]){code}
After I fixed it, groupings set will be saved.
{code:java}
LogicalAggregate(group=[{0, 1, 2}], groups=[[{0, 1}]])
LogicalAggregate(group=[{0, 1, 7}], job_num=[COUNT($2)])
LogicalTableScan(table=[[scott, EMP]]{code}
Although the user will not write such SQL directly, it does happen after the
logic is complicated, and the user will be confused about the wrong data.
was:
UT:
{code:java}
builder.scan("EMP")
.aggregate(builder.groupKey(0, 1, 7),
builder.aggregateCall(SqlStdOperatorTable.COUNT,
builder.field("JOB")).as("job_num"))
.aggregate(
builder.groupKey(ImmutableBitSet.of(0, 1, 2),
(Iterable<ImmutableBitSet>)
ImmutableList.of(ImmutableBitSet.of(0, 1))))
// GROUP BY 0,1,2 GROUPING SETS((0, 1))
.build();
{code}
Before I fixed it, you can see groupings set are missing because LogicalProject.
{code:java}
LogicalProject(EMPNO=[$0], ENAME=[$1], DEPTNO=[$2])
LogicalAggregate(group=[{0, 1, 7}], job_num=[COUNT($2)])
LogicalTableScan(table=[[scott, EMP]]){code}
After I fixed it, groupings set will be saved.
{code:java}
LogicalAggregate(group=[{0, 1, 2}], groups=[[{0, 1}]])
LogicalAggregate(group=[{0, 1, 7}], job_num=[COUNT($2)])
LogicalTableScan(table=[[scott, EMP]]{code}
Although the user will not write such SQL directly, it does happen after the
logic is complicated, and the user will be confused about the wrong data.
> When group by are same as sub-query, grouping sets are missing
> --------------------------------------------------------------
>
> Key: CALCITE-4665
> URL: https://issues.apache.org/jira/browse/CALCITE-4665
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: xiejiajun
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UT:
> {code:java}
> builder.scan("EMP")
> .aggregate(builder.groupKey(0, 1, 7),
> builder.aggregateCall(SqlStdOperatorTable.COUNT,
> builder.field("JOB")).as("job_num"))
> .aggregate(
> builder.groupKey(ImmutableBitSet.of(0, 1, 2),
> (Iterable<ImmutableBitSet>)
> ImmutableList.of(ImmutableBitSet.of(0, 1))))
> // GROUP BY 0,1,2 GROUPING SETS((0, 1))
> .build();
> {code}
> Before I fixed it, you can see groupings set are missing because
> LogicalProject.
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], DEPTNO=[$2])
> LogicalAggregate(group=[{0, 1, 7}], job_num=[COUNT($2)])
> LogicalTableScan(table=[[scott, EMP]]){code}
> After I fixed it, groupings set will be saved.
> {code:java}
> LogicalAggregate(group=[{0, 1, 2}], groups=[[{0, 1}]])
> LogicalAggregate(group=[{0, 1, 7}], job_num=[COUNT($2)])
> LogicalTableScan(table=[[scott, EMP]]{code}
> Although the user will not write such SQL directly, it does happen after
> the logic is complicated, and the user will be confused about the wrong data.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
