[
https://issues.apache.org/jira/browse/CALCITE-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885546#comment-16885546
]
Julian Hyde commented on CALCITE-3113:
--------------------------------------
It seems necessary that the before and after row types have the same number and
type of fields, not necessarily the same names. There's probably a check for
that elsewhere in the code, since it's a common requirement.
I see that the PR has assert statements inside for loops. The goal is to avoid
the effort of checking if asserts are disabled. Therefore the pattern {{assert
xxxIsValid(x, Litmus.THROW)}}, where the method {{xxxIsValid()}} does the for
loops, is a good and efficient one.
> Equivalent MutableAggregates with different row types fail with AssertionError
> ------------------------------------------------------------------------------
>
> Key: CALCITE-3113
> URL: https://issues.apache.org/jira/browse/CALCITE-3113
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.19.0
> Reporter: Feng Zhu
> Priority: Major
> Labels: pull-request-available
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Add test case in MaterializationTest:
> {code:java}
> @Test public void testAggregateAlias() {
> checkMaterialize(
> "select count(*) as c from \"emps\" group by \"empid\"",
> "select count(*) + 1 as c from \"emps\" group by \"empid\"");
> }
> {code}
> It fails due to different rowtype.
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:504)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:465)
> at
> org.apache.calcite.plan.MaterializedViewSubstitutionVisitor.go(MaterializedViewSubstitutionVisitor.java:56)
> at
> org.apache.calcite.plan.RelOptMaterializations.substitute(RelOptMaterializations.java:200)
> at
> org.apache.calcite.plan.RelOptMaterializations.useMaterializedViews(RelOptMaterializations.java:72)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerMaterializations(VolcanoPlanner.java:347)
> {code}
> However, according to MutableAggregate's hashCode&equals implementation, this
> materialization can be reused, i.e., queryDescedant=targetDescendant.
> {code:java}
> queryDescendant: RecordType(JavaType(int) empid, BIGINT $f1)
> =============================================================================
> Aggregate(groupSet: {0}, groupSets: [{0}], calls: [COUNT()])
> Project(projects: [$0])
> Scan(table: [hr, emps])
> targetDescendant: RecordType(JavaType(int) empid, BIGINT C)
> =============================================================================
> Aggregate(groupSet: {0}, groupSets: [{0}], calls: [COUNT()])
> Project(projects: [$0])
> Scan(table: [hr, emps])
> {code}
> So, how can we align them?
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
