Re: [DISCUSS] Move CalciteAssert and similar "test framework" classes to its own testlib module
Jin>Some of my users write tests based on functionalities provided from Calcite Jin>test framework Frankly speaking, it was somewhat surprising for me, and it does bring extra demand for having a proper calcite-test-framework. The naming is hard, however, I would suggest artifactId=calcite-test-framework. Any thoughts? It turns out Flink depends on Calcite's test code like FlinkSqlParserImplTest extends calcite.SqlParserTest: https://issues.apache.org/jira/browse/CALCITE-2905?focusedCommentId=17002741&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17002741 For instance, a year or so ago I refactored SqlTestFactory (for enabling SqlAdvisor tests) in https://github.com/apache/calcite/commit/96b28f7ba11de22a68d984de6b6b88311cc2c57e , and I was not expecting that someone else might use that test code Vladimir
Contribute to Calcite
Hi Guys, I want to contribute to Apache Calcite. Would you please give me the permission as a contributor? My JIRA ID is yimeisun.
Re: Contribute to Calcite
I've added you as a contributor. Thanks! -- Michael Mior mm...@apache.org Le mer. 25 déc. 2019 à 06:59, SUN RUN a écrit : > > Hi Guys, > > I want to contribute to Apache Calcite. > Would you please give me the permission as a contributor? > My JIRA ID is yimeisun.
[jira] [Created] (CALCITE-3631) Support SQL hints for Calc
Shuo Cheng created CALCITE-3631: --- Summary: Support SQL hints for Calc Key: CALCITE-3631 URL: https://issues.apache.org/jira/browse/CALCITE-3631 Project: Calcite Issue Type: Sub-task Reporter: Shuo Cheng Calc combines the functionality of Project, and it's created in the later stages of optimization. So it's necessary to make Calc hintable now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3632) Add IntersectToIntersectUnifyRule in SubstitutionVisitor
xzh_dz created CALCITE-3632:
---
Summary: Add IntersectToIntersectUnifyRule in SubstitutionVisitor
Key: CALCITE-3632
URL: https://issues.apache.org/jira/browse/CALCITE-3632
Project: Calcite
Issue Type: Wish
Reporter: xzh_dz
when i run those code as below, i got some error messages.
{code:java}
//MaterializationTest
@Test public void testJoinToJoin0() {
String mv = ""
+ "select \"deptno\" from\n"
+ "\"emps\" intersect select \"deptno\" from \"depts\"";
String query = ""
+ "select \"deptno\" from\n"
+ "\"depts\" intersect select \"deptno\" from \"emps\"";
checkMaterialize(mv, query, true);
}
{code}
java.lang.AssertionError:
Expected: a string containing "EnumerableTableScan(table=[[hr, m0]])"
but: was "PLAN=EnumerableCalc(expr#0..1=[{inputs}], expr#2=[2:BIGINT],
expr#3=[=($t1, $t2)], deptno=[$t0], $condition=[$t3])\n
EnumerableAggregate(group=[{0}], agg#0=[COUNT()])\n
EnumerableUnion(all=[true])\n EnumerableAggregate(group=[{0}],
agg#0=[COUNT()])\nEnumerableTableScan(table=[[hr, depts]])\n
EnumerableAggregate(group=[{1}], agg#0=[COUNT()])\n
EnumerableTableScan(table=[[hr, emps]])\n\n"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.calcite.test.CalciteAssert.lambda$checkResultContains$7(CalciteAssert.java:429)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:544)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1514)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1446)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1512)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.explainMatches(CalciteAssert.java:1609)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Personally, I would opt for a more permissive build. Unexpected line endings is kind of subjective. I guess there are people who use Windows and they still have their editors configured to use LF endings. Moreover, checking other opensource projects it is kind of rare to release source code in multiple formats with different line endings. I didn't attempt to build these projects but I would be surprised if the build fails depending on the OS. Indeed in some cases these might lead to test failures or other weird behavior but these should not happen very often. On Tue, Dec 24, 2019 at 3:44 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Stamatis> do we have another option so that the build does not fail on > Windows? > > It boils down to a question: should the build fail if the source files > contain unexpected line endings? > > Suppose someone uses Windows, and they create test_sql_plan.txt file with > wrong line endings (==LF). > Should the build fail? > > Suppose someone uses Linux and they create a file with CRLF line endings. > Should the build fail? > > Of course, Git will normalize the line endings at commit time, and > everybody who pulls that commit would get the normalized file. > > However, if the local file is different from what Git expects, it might > result in hard to understand conditions like > unexpected test failures or inability to reproduce CI test failure. > > Vladimir >
