Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-489

Teach CalciteAssert to respect multiple settings

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-incubating
    • Fix Version/s: 1.0.0-incubating
    • Component/s: None
    • Labels:

      Description

      Currently CalciteAssert allows to specify either custom connection properties via with(Map) or custom schema via with(String, Object).

      Often it is required to set both simultaneously:
      For instance, lex=JAVA is an easy way to write queries without quotes.
      For testing correlation runtime, it is required to set forceDecorrelate=true/false.

        Issue Links

          Activity

          Hide
          julianhyde Julian Hyde added a comment -

          Closing now that 1.0.0-incubating has been released.

          Show
          julianhyde Julian Hyde added a comment - Closing now that 1.0.0-incubating has been released.
          Show
          vladimirsitnikov Vladimir Sitnikov added a comment - Fixed in https://git-wip-us.apache.org/repos/asf?p=incubator-calcite.git;a=commit;h=986f994349a92ba2644f7384cefaccd165735832
          Hide
          vladimirsitnikov Vladimir Sitnikov added a comment -

          Please review the fix in https://github.com/apache/incubator-calcite/pull/42

          I've removed quotes from the README.md. I believe it is much more readable.

          Show
          vladimirsitnikov Vladimir Sitnikov added a comment - Please review the fix in https://github.com/apache/incubator-calcite/pull/42 I've removed quotes from the README.md. I believe it is much more readable.
          Hide
          julianhyde Julian Hyde added a comment -

          The test infrastructure isn't perfect, and never will be. People should enhance it as they add tests. As long as there is a way to concisely write a test case that tests the functionality you want to test, that is good enough.

          Show
          julianhyde Julian Hyde added a comment - The test infrastructure isn't perfect, and never will be. People should enhance it as they add tests. As long as there is a way to concisely write a test case that tests the functionality you want to test, that is good enough.
          Hide
          vladimirsitnikov Vladimir Sitnikov added a comment -

          Need more corrections.

          I believe we should avoid mess with multiple ConnectionFactories implementations.

          Otherwise things like unimplmentedexception would be here and there.
          And some surprises would be hidden: CalciteAssert.that().with("prop", "value").with(CalciteAssert.Config.FOODMART_CLONE) silently ignores "prop". I believe it is bad.

          For instance:

            @Test public void testJoinCorreScalarSubQ()
                throws ClassNotFoundException, SQLException {
              CalciteAssert.that()
                  .with(CalciteAssert.Config.FOODMART_CLONE)
                  .with(CalciteConnectionProperty.LEX.name(), Lex.JAVA.toString())
                  .query("select e.employee_id, d.department_id "
                          + " from employee e, department d "
                          + " where e.department_id = d.department_id and "
                          + "       e.salary > (select avg(e2.salary) "
                          + "                       from employee e2 "
                          + " where e2.store_id = e.store_id)"
                  ).returnsCount(0);
            }
          

          Fails with:

          java.lang.UnsupportedOperationException
          	at org.apache.calcite.test.CalciteAssert$AbstractConnectionFactory.with(CalciteAssert.java:949)
          	at org.apache.calcite.test.CalciteAssert$AssertThat.with(CalciteAssert.java:799)
          	at org.apache.calcite.test.JdbcTest.testJoinCorreScalarSubQ2(JdbcTest.java:4235)
          	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
          	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
          	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
          	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
          	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
          	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
          	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
          	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
          	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
          	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
          	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
          	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
          	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
          	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
          	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
          	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74)
          	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:211)
          	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:67)
          	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
          	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
          
          Show
          vladimirsitnikov Vladimir Sitnikov added a comment - Need more corrections. I believe we should avoid mess with multiple ConnectionFactories implementations. Otherwise things like unimplmentedexception would be here and there. And some surprises would be hidden: CalciteAssert.that().with("prop", "value").with(CalciteAssert.Config.FOODMART_CLONE) silently ignores "prop". I believe it is bad. For instance: @Test public void testJoinCorreScalarSubQ() throws ClassNotFoundException, SQLException { CalciteAssert.that() .with(CalciteAssert.Config.FOODMART_CLONE) .with(CalciteConnectionProperty.LEX.name(), Lex.JAVA.toString()) .query( "select e.employee_id, d.department_id " + " from employee e, department d " + " where e.department_id = d.department_id and " + " e.salary > (select avg(e2.salary) " + " from employee e2 " + " where e2.store_id = e.store_id)" ).returnsCount(0); } Fails with: java.lang.UnsupportedOperationException at org.apache.calcite.test.CalciteAssert$AbstractConnectionFactory.with(CalciteAssert.java:949) at org.apache.calcite.test.CalciteAssert$AssertThat.with(CalciteAssert.java:799) at org.apache.calcite.test.JdbcTest.testJoinCorreScalarSubQ2(JdbcTest.java:4235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:211) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
          Show
          julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/3fccc08e .
          Hide
          vladimirsitnikov Vladimir Sitnikov added a comment - - edited

          Fixed in https://git-wip-us.apache.org/repos/asf?p=incubator-calcite.git;a=commitdiff;h=696da1685f6c86b6e90abfbe369ea861deeb72d5

          Update: No fix was really committed.

          Here's relevant commit part:

          +    Bug.remark(
          +        "CALCITE-489 - Teach CalciteAssert to respect multiple settings");
          Show
          vladimirsitnikov Vladimir Sitnikov added a comment - - edited Fixed in https://git-wip-us.apache.org/repos/asf?p=incubator-calcite.git;a=commitdiff;h=696da1685f6c86b6e90abfbe369ea861deeb72d5 Update: No fix was really committed. Here's relevant commit part: + Bug.remark( + "CALCITE-489 - Teach CalciteAssert to respect multiple settings" );

            People

            • Assignee:
              Unassigned
              Reporter:
              vladimirsitnikov Vladimir Sitnikov
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development