[ 
https://issues.apache.org/jira/browse/CALCITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16735061#comment-16735061
 ] 

Julian Hyde commented on CALCITE-2764:
--------------------------------------

I'm sorry, I just don't buy it. A set of traits is not the same as a trait. 
Multi-sorted relations are rare in practice. Multi-distributed relations don't 
exist (except the empty relation). I'm not sure about other traits, but again, 
I'm doubtful.

You're inventing requirements to match what you thought was the design. That's 
wrong.

The principle of least surprise would be to do away with RelCompositeTrait, and 
make sure that sets of traits look different from individual traits, but it's 
probably not worth the effort. Or to throw when someone calls satisfies with a 
composite trait on the RHS.

> 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)

Reply via email to