Danny Chen created CALCITE-3608:
---
Summary: Promote RelOptUtil.createCastRel to not create new
projection if the input rel is already a project
Key: CALCITE-3608
URL:
xzh_dz created CALCITE-3607:
---
Summary: Support LogicalTableModify in RelShuttle
Key: CALCITE-3607
URL: https://issues.apache.org/jira/browse/CALCITE-3607
Project: Calcite
Issue Type: Wish
Hi, Vladimir
> I suggest we do not publish testlib artifacts to Nexus (who needs
> Calcite-related assertions and things like that?)
+1 to have the module be published.
Some of my users write tests based on functionalities provided from Calcite
test framework.
Best,
Jin
Michael Mior
Ran Cao created CALCITE-3606:
Summary: batch insert failed
Key: CALCITE-3606
URL: https://issues.apache.org/jira/browse/CALCITE-3606
Project: Calcite
Issue Type: Wish
Components: core
Some updates.
Recently i took a look at their doc and source code, and found this project
uses SQL parsing and Relational algebra of Calcite to get query plan, and also
translates to spark SQL for joining different datasources, or corresponding
query for single datasource.
Although it
I've used the new version calcite with new version of IntelliJ, everything
works. I like that.
I can see valadmir put some efforts in this, I respect that. and all effort
put in to the codebase should be respected.
from my side, I don't contribute as much now, but occasionally I would look
at the
Sounds good to me. Although I'd still like to see the module be
published. I'm currently using it my notebooks project
(https://github.com/michaelmior/calcite-notebooks) because some of the
test code removes boilerplate when writing examples.
--
Michael Mior
mm...@apache.org
Le mar. 17 déc. 2019
Le mar. 17 déc. 2019 à 15:26, Vladimir Sitnikov
a écrit :
>
> Vladimir>Quidem, CalciteAssert
> Michael>If you want to propose removing either of these, we could have a
> Michael>discussion about it, but you're talking about code which is already
> Michael>heavily used throughout Calcite.
>
> The
Undeniably multi-line strings can improve the readability of the code and
facilitate reviews but I would prefer if we didn't refactor existing tests
from Java to Kotlin mainly for two reasons:
1. Losing the history is an important disadvantage for me. Quite often, I
find my self looking in the
It probably makes sense.
But I am exhausted, utterly exhausted, with the "moving stuff around"
that Vladimir has done over the last few months.
For example. I ran into a problem running SqlPrettyWriterTest a few
days ago[1] that did not exist a few months ago (before the
gradle/junit upgrade).
Hi,
Currently
org.apache.calcite.test.CalciteAssert, org.apache.calcite.util.TestUtil,
and probably other classes are hard to find.
I suggest we create a testlib module (or something like that), that would
contain "test framework" code.
That would make test framework easier to discover (one
Vladimir>Quidem, CalciteAssert
Michael>If you want to propose removing either of these, we could have a
Michael>discussion about it, but you're talking about code which is already
Michael>heavily used throughout Calcite.
The point of "we assume contributors are good at Java, thus we must keep
the
Le mar. 17 déc. 2019 à 10:59, Vladimir Sitnikov
a écrit :
>
> Michael>However, we know our
> Michael>current contributors are reasonably fluent in Java. I'm not sure
> about
> Michael>Kotlin.
>
> 1) New contributions are not fluent in Quidem at all
> 2) New contributions are not fluent in
Michael>However, we know our
Michael>current contributors are reasonably fluent in Java. I'm not sure
about
Michael>Kotlin.
1) New contributions are not fluent in Quidem at all
2) New contributions are not fluent in CalciteAssert at all
3) As I said, if someone does not want to get familiar with
Hello Calcite Team,
I believe products are advancing through constant improvements rather than
freezing codebase. Why does nobody consider Kotlin as an opportunity to
improve Calcite? Indeed, most of the replies sound like: "I don't want to
learn Kotlin because it requires extra efforts, etc,
Le mar. 17 déc. 2019 à 03:30, Vladimir Sitnikov
a écrit :
>
> Kevin>Focusing on the technical side of things, I agree that introducing a
> new
> Kevin>language is of little benefit currently
>
> Kevin, what is your opinion on removing Quidem language?
> Focusing on the technical side, it is a
Given the discussion on [1] the problem of building .tar.gz on Windows was
anticipated so I am not changing my vote.
Nevertheless it might be a bit annoying for Windows users so we have to see
how we can improve on this aspect.
[1]
MacOS 10.14, JDK 1.8.0_161, Gradle 6.0.1
* Checked signatures and checksums OK
* Went over release note OK
* Run build and tests (./gradlew clean build) on git repo OK
* Run build and Calcite tests on Calcite current master (./gradlew clean
build) with Avatica 1.16.0 OK
* Run diff between
Contributors and Committers who have voted, please review this issue and
let me know if this changes your vote.
On 17/12/2019 8:07 pm, Vladimir Sitnikov wrote:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc1/apache-calcite-avatica-1.16.0-src.tar.gz
does not
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc1/apache-calcite-avatica-1.16.0-src.tar.gz
does not build if Windows with default settings is used.
The error messages for "./gradlew build" are as follows:
-// dependency on it during compilation\n
Kevin>Focusing on the technical side of things, I agree that introducing a
new
Kevin>language is of little benefit currently
Kevin, what is your opinion on removing Quidem language?
Focusing on the technical side, it is a standalone language.
The language is not Java, it has limited tooling, it
21 matches
Mail list logo
