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.
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
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.
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.
" 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
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.
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
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
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
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:
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
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
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
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,
14 matches
Mail list logo
