[
https://issues.apache.org/jira/browse/CALCITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733472#comment-16733472
]
Julian Hyde commented on CALCITE-2764:
--------------------------------------
Thanks for backing out the change.
My intent was that composite traits should only occur on the left-hand side of
"satisfies". We have a RelNode on the left that has composite traits (e.g.
sorted by (X) and also sorted by (Y, Z)). On the right side we have a desired
trait in order to match a rule. This trait is never composite.
The "satisfies" relation is similar to the "contains" relation on sets. The set
\{A, B} contains A, but it does not contain itself, \{A, B}. We complicate
things by allowing singleton sets to also stand for elements, but that is the
basic idea.
The reason that I believe that this so-called bug should not be fixed is
because if some code is running into this issue then it probably has composite
traits in rule operands (or something like that), which is not what I planned
in the volcano engine. So that code needs to be fixed, not this so-called bug.
The fix for this so-called bug is probably to throw an error if it sees a
composite trait on the right-hand side.
> RelCompositeTrait#satisfies does not work for non-trivial traits
> ----------------------------------------------------------------
>
> Key: CALCITE-2764
> URL: https://issues.apache.org/jira/browse/CALCITE-2764
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.18.0
> Reporter: Vladimir Sitnikov
> Assignee: Vladimir Sitnikov
> Priority: Major
> Fix For: 1.19.0
>
>
> {noformat}java.lang.AssertionError: [[0, 1], [1]].satisfies([[0, 1], [1]])
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.calcite.plan.RelTraitTest.assertSatisfies(RelTraitTest.java:81)
> at
> org.apache.calcite.plan.RelTraitTest.compositeSatisfies(RelTraitTest.java:77)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 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.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.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
