Calcite-Master - Build # 1504 - Still Failing
The Apache Jenkins build system has built Calcite-Master (build #1504) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/1504/ to view the results.
Re: Calcite-Master - Build # 1503 - Failure
This could be fixed by https://github.com/apache/calcite/pull/1663. -Rui On Sun, Dec 15, 2019 at 9:20 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > The Apache Jenkins build system has built Calcite-Master (build #1503) > > Status: Failure > > Check console output at https://builds.apache.org/job/Calcite-Master/1503/ > to view the results.
Re: [DISCUSS] Tests vs multiline strings
Feng>Introducing another language It is the same language that is used for the build scripts, so it is not a new language. Danny> in the code evolving and the Scala has many Danny> tricky problems especially the version compatibility Kotlin has strong backward compatibility. Julian>Transitioning our tests to a different language (Kotlin) is a Julian> drastic solution. It requires developers to understand a new language, Note: most of the time, test code is just a glue code between input data and asserts. The complicated logic is not there (which is good by the way). At the same time, it means it will be very little new to understand. Vladimir
Calcite-Master - Build # 1503 - Failure
The Apache Jenkins build system has built Calcite-Master (build #1503) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/1503/ to view the results.
Re: [DISCUSS] Tests vs multiline strings
" It is pretty good as a pure Java project" +1 for Danny's comment. Introducing another language (without strong demands) brings burden for project maintenance and evolution. Best, Feng Danny Chan 于2019年12月16日周一 上午11:34写道： > I also have the same concern with Julian, in Apache Flink SQL, we did a > lot of code with Scala, but in the code evolving and the Scala has many > tricky problems especially the version compatibility. So finally, we decide > to move on to Java code: rewrite exiting Scala code to Java again. > > I don’t think Kotlin is more popular than Scala or better than Scala, so > I’m scared for this suggestion. > > I also didn’t want Calcite to repeat the mistake, it is pretty good as a > pure Java project. > > BTW, I always saw some new code as Kotlin in Calcite[1](Some of them are > test APIs), maybe we should change them back to Java. > > [1] > https://github.com/apache/calcite/commit/0d6bec4140da46af07d58cf07a5e682d61529603 > > Best, > Danny Chan > 在 2019年12月16日 +0800 AM9:02，Julian Hyde ，写道： > > I don't think we should do this. > > > > Multi-line strings are a bit unwieldy, but they're not a major > > problem. Transitioning our tests to a different language (Kotlin) is a > > drastic solution. It requires developers to understand a new language, > > and it loses all history from the source files. > > > > Julian > > > > On Sun, Dec 15, 2019 at 4:37 AM Vladimir Sitnikov > > wrote: > > > > > > I've filed two PRs to evaluate the impact of the replacement. > > > > > > $ to _: https://github.com/apache/calcite/pull/1659 > > > 203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run > > > :core:test > > > > > > $ to #: https://github.com/apache/calcite/pull/1660 > > > 196.7sec, 5510 completed, 53 failed, 91 skipped, Gradle Test Run > > > :core:test > > > > > > There are test failures, however, both of them are almost ready. > > > > > > Both $ and _ are valid "Java identifier start" characters, so variable > name > > > like _3 is valid. > > > If we use # instead of $, then code generator needs to be updated as > well > > > as it sometimes uses Java variables like $3, and #3 would become > invalid. > > > > > > Any thoughts? > > > > > > Vladimir >
Re: How to keep quotes in SqlIdentifier?
Dear 月宫的木马兔 ~ You are right, we actually does not need to keep these quotes characters in the SqlIdentifier, what the quote character is depends on the sql conformance you choose[1]. Unless if you want to unparse these SqlIdentifier, you can config your write with the sql conformance you want. [1] https://github.com/apache/calcite/blob/547e49c1c37554f3bff904d5266d9e1c671e98f0/core/src/main/java/org/apache/calcite/sql/validate/SqlConformance.java#L34 Best, Danny Chan 在 2019年12月14日 +0800 AM10:03，月宫的木马兔 ，写道： > Hi, > I got the SqlNode by using SqlParse.parseQuery() (Sql bellow), but I can > not find the back_tick in SqlIdentifer > > Sql: > > SELECT `sql`,id1 FROM testdata > > Debug with IDEA: > <> >
Re: [DISCUSS] Tests vs multiline strings
I also have the same concern with Julian, in Apache Flink SQL, we did a lot of code with Scala, but in the code evolving and the Scala has many tricky problems especially the version compatibility. So finally, we decide to move on to Java code: rewrite exiting Scala code to Java again. I don’t think Kotlin is more popular than Scala or better than Scala, so I’m scared for this suggestion. I also didn’t want Calcite to repeat the mistake, it is pretty good as a pure Java project. BTW, I always saw some new code as Kotlin in Calcite[1](Some of them are test APIs), maybe we should change them back to Java. [1] https://github.com/apache/calcite/commit/0d6bec4140da46af07d58cf07a5e682d61529603 Best, Danny Chan 在 2019年12月16日 +0800 AM9:02，Julian Hyde ，写道： > I don't think we should do this. > > Multi-line strings are a bit unwieldy, but they're not a major > problem. Transitioning our tests to a different language (Kotlin) is a > drastic solution. It requires developers to understand a new language, > and it loses all history from the source files. > > Julian > > On Sun, Dec 15, 2019 at 4:37 AM Vladimir Sitnikov > wrote: > > > > I've filed two PRs to evaluate the impact of the replacement. > > > > $ to _: https://github.com/apache/calcite/pull/1659 > > 203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run > > :core:test > > > > $ to #: https://github.com/apache/calcite/pull/1660 > > 196.7sec, 5510 completed, 53 failed, 91 skipped, Gradle Test Run > > :core:test > > > > There are test failures, however, both of them are almost ready. > > > > Both $ and _ are valid "Java identifier start" characters, so variable name > > like _3 is valid. > > If we use # instead of $, then code generator needs to be updated as well > > as it sometimes uses Java variables like $3, and #3 would become invalid. > > > > Any thoughts? > > > > Vladimir
Re: [DISCUSS] Tests vs multiline strings
Before coming to Calcite, I works quite some time on Scala. The code style shares some similarities with Kotlin -- It's much simple and easier to read when you write a test. But we should think twice whether to bring in another language. To answer Haisheng's question: Because default lex config is Lex.ORACLE. Best, Jin Chunwei Lei 于2019年12月16日周一 上午10:34写道： > I agree with Julian. > > Changing to Kotlin needs lots of error, but gets a little gain. Besides, It > costs much more > time to write a test if developers are not familiar with Kotlin. I > prefer to use Java as it is now. > > > Best, > Chunwei > > > On Mon, Dec 16, 2019 at 9:02 AM Julian Hyde wrote: > > > I don't think we should do this. > > > > Multi-line strings are a bit unwieldy, but they're not a major > > problem. Transitioning our tests to a different language (Kotlin) is a > > drastic solution. It requires developers to understand a new language, > > and it loses all history from the source files. > > > > Julian > > > > On Sun, Dec 15, 2019 at 4:37 AM Vladimir Sitnikov > > wrote: > > > > > > I've filed two PRs to evaluate the impact of the replacement. > > > > > > $ to _: https://github.com/apache/calcite/pull/1659 > > > 203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run > > > :core:test > > > > > > $ to #: https://github.com/apache/calcite/pull/1660 > > > 196.7sec, 5510 completed, 53 failed, 91 skipped, Gradle Test Run > > > :core:test > > > > > > There are test failures, however, both of them are almost ready. > > > > > > Both $ and _ are valid "Java identifier start" characters, so variable > > name > > > like _3 is valid. > > > If we use # instead of $, then code generator needs to be updated as > well > > > as it sometimes uses Java variables like $3, and #3 would become > invalid. > > > > > > Any thoughts? > > > > > > Vladimir > > >
Re: [DISCUSS] Tests vs multiline strings
I agree with Julian. Changing to Kotlin needs lots of error, but gets a little gain. Besides, It costs much more time to write a test if developers are not familiar with Kotlin. I prefer to use Java as it is now. Best, Chunwei On Mon, Dec 16, 2019 at 9:02 AM Julian Hyde wrote: > I don't think we should do this. > > Multi-line strings are a bit unwieldy, but they're not a major > problem. Transitioning our tests to a different language (Kotlin) is a > drastic solution. It requires developers to understand a new language, > and it loses all history from the source files. > > Julian > > On Sun, Dec 15, 2019 at 4:37 AM Vladimir Sitnikov > wrote: > > > > I've filed two PRs to evaluate the impact of the replacement. > > > > $ to _: https://github.com/apache/calcite/pull/1659 > > 203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run > > :core:test > > > > $ to #: https://github.com/apache/calcite/pull/1660 > > 196.7sec, 5510 completed, 53 failed, 91 skipped, Gradle Test Run > > :core:test > > > > There are test failures, however, both of them are almost ready. > > > > Both $ and _ are valid "Java identifier start" characters, so variable > name > > like _3 is valid. > > If we use # instead of $, then code generator needs to be updated as well > > as it sometimes uses Java variables like $3, and #3 would become invalid. > > > > Any thoughts? > > > > Vladimir >
[jira] [Created] (CALCITE-3602) Git should ignore .DS_Store files on macOS
Chenxiao Mao created CALCITE-3602: - Summary: Git should ignore .DS_Store files on macOS Key: CALCITE-3602 URL: https://issues.apache.org/jira/browse/CALCITE-3602 Project: Calcite Issue Type: Improvement Components: build Affects Versions: 1.21.0 Reporter: Chenxiao Mao I'm working on macOS and found .DS_Store files automatically generated by OS very annoying. We should add .DS_Store to .gitignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: How to keep quotes in SqlIdentifier?
I bet that the SqlIdentifier for the first item in the SELECT clause has one component, and that component is quoted: SqlIdentifier id; id.isComponentQuoted(0); // evaluates true The name of the component will be "sql" (without back-ticks). The second item will also have one component, not quoted, whose name is "id1" or "ID1" (depending on whether the parser is configured to convert unquoted identifiers to upper-case). Julian On Sat, Dec 14, 2019 at 2:11 AM Muhammad Gelbana wrote: > > I don't find it correct to have quotes, double-quotes, backticks or > anything other than the identifier name in the SqlNode's identifier. If you > need it, you can just add it your self. > > But why do you want to have the identifier this way ? May be there is > another way to achieve your goal ? > > > On Sat, Dec 14, 2019 at 4:03 AM 月宫的木马兔 wrote: > > > Hi, > > > > I got the SqlNode by using SqlParse.parseQuery() (Sql bellow), but I can > > not find the back_tick in SqlIdentifer > > > > Sql: > > > > SELECT `sql`,id1 FROM testdata > > > > Debug with IDEA: > > > > > >
Re: [DISCUSS] Tests vs multiline strings
I don't think we should do this. Multi-line strings are a bit unwieldy, but they're not a major problem. Transitioning our tests to a different language (Kotlin) is a drastic solution. It requires developers to understand a new language, and it loses all history from the source files. Julian On Sun, Dec 15, 2019 at 4:37 AM Vladimir Sitnikov wrote: > > I've filed two PRs to evaluate the impact of the replacement. > > $ to _: https://github.com/apache/calcite/pull/1659 > 203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run > :core:test > > $ to #: https://github.com/apache/calcite/pull/1660 > 196.7sec, 5510 completed, 53 failed, 91 skipped, Gradle Test Run > :core:test > > There are test failures, however, both of them are almost ready. > > Both $ and _ are valid "Java identifier start" characters, so variable name > like _3 is valid. > If we use # instead of $, then code generator needs to be updated as well > as it sometimes uses Java variables like $3, and #3 would become invalid. > > Any thoughts? > > Vladimir
[jira] [Created] (CALCITE-3601) Update cassandra, elasticsearch, geode, linq4j, mongodb test upgrade from junit4 to junit5
Forward Xu created CALCITE-3601: --- Summary: Update cassandra, elasticsearch, geode, linq4j, mongodb test upgrade from junit4 to junit5 Key: CALCITE-3601 URL: https://issues.apache.org/jira/browse/CALCITE-3601 Project: Calcite Issue Type: Test Reporter: Forward Xu Update `cassandra, elasticsearch, geode, linq4j, and mongodb` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Tests vs multiline strings
I've filed two PRs to evaluate the impact of the replacement. $ to _: https://github.com/apache/calcite/pull/1659 203.3sec, 5510 completed, 3 failed, 91 skipped, Gradle Test Run :core:test $ to #: https://github.com/apache/calcite/pull/1660 196.7sec, 5510 completed, 53 failed, 91 skipped, Gradle Test Run :core:test There are test failures, however, both of them are almost ready. Both $ and _ are valid "Java identifier start" characters, so variable name like _3 is valid. If we use # instead of $, then code generator needs to be updated as well as it sometimes uses Java variables like $3, and #3 would become invalid. Any thoughts? Vladimir
