Wang Yanlin created CALCITE-3583:
Summary: Support serialized to json and deserialized from json for
Exchange relation operator
Key: CALCITE-3583
URL: https://issues.apache.org/jira/browse/CALCITE-3583
Julian>I’m curious why the instructions include ‘-Prelease’.
The instructions in the vote mail provide a way to reproduce the archive.
In other words, the build would produce exactly the same file names and
contents (with the same checksums)
Julian>People should be able to unpack and build the
Kevin>fails on the zip when extracted.
zip has CRLF line endings, and tar.gz has LF line endings, so you should
select
the archive based on your needs and environment setup.
The archives are not identical on purpose.
Vladimir
I believe we stopped releasing zips a while back in CALCITE-2333[1], so
the gradle task needs to be updated to not build any zip files.
In past releases (1.15.0-rc0), we also provided a hash of the signature:
Yes, virtualization is one of Calcite’s goals. In fact, when I created Calcite
I was thinking about virtualization + in-memory materialized views. Not only
the Spark convention but any of the “engine” conventions (Drill, Flink, Beam,
Enumerable) could be used to create a virtual query engine.
Hi Vladimir,
Sorry for my late reply.
WRT join planning, it is not required to put join reordering rule into the HEP
planner. It can also be put into Volcano planner. Indeed, it is not ideal for
the join ordering rule to generate a single plan. We can create a nother rule
to generate multiple
+0
I’m curious why the instructions include ‘-Prelease’. People should be able to
unpack and build the distribution and do a ’normal’ build.
Sure, it is useful to be able to reproduce the release build, but it’s much
more important that a normal build works.
And, related, I would not include
-1
"./gradlew build -Prelease -PskipSigning" fails on the zip when extracted.
Looks like it has windows line endings and doesn't pass checks.
Looks like we are publishing both tar.gz and zip now?
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc0/
We
didn't do that
Rui Wang created CALCITE-3582:
-
Summary: Make StructFlatterner configurable in PlannerImpl
Key: CALCITE-3582
URL: https://issues.apache.org/jira/browse/CALCITE-3582
Project: Calcite
Issue Type:
It's been some time that I didn't look into the code but the most recent
Hive paper [1] mostly talks about Calcite in the query optimization section
so I have to say I am a bit surprised.
[1] https://arxiv.org/pdf/1903.10970.pdf
On Mon, Dec 9, 2019 at 6:21 PM Vladimir Ozerov wrote:
> After
Hello,
Sorry for the long delay on this thread. Recently I heard about requests on
how to deal with STRUCT without flattening it again in BeamSQL. Also I
realized Flink has already disabled it in their codebase[1]. I did try to
remove STRUCT flattening and run unit tests of calcite core to see
I mean that there are a few people who are a bit skeptical with the change
so it seems that more convincing elements are needed.
>From my side, I would like to note that the Checkstyle related problems
that I encountered are reproducible (see CALCITE-3581 [1]).
I cannot yet explain why but with
Stamatis Zampetakis created CALCITE-3581:
Summary: Gradle build hangs if there Checkstyle violations
Key: CALCITE-3581
URL: https://issues.apache.org/jira/browse/CALCITE-3581
Project: Calcite
I recently contacted one of the active contributors asking about the
purpose of the project and here's his reply:
>From my understanding, Quicksql is a data virtualization platform. It can
> query multiple data sources altogether and in a distributed way; Say, you
> can write a SQL with a MySql
We might be inventing requirements here, in order to justify a “cool” technical
change.
I don’t think there is a strong requirement for multiple versions of the site.
(Sure, it would be nice.)
This thread started with Stamatis pointing out that it was complicated to
update the site. If we
In the short term we should try to do our best to follow the existing
workflow.
In the medium term we shall hope that things will be easier with the
automated build of the website.
In the longer term, I would really prefer to migrate towards a solution
like the one proposed by Vladimir.
As I
In package-info.java files we need to add the Javadoc right above the
package declaration which is not the case for normal files.
I think that having an extra line between the header and the Javadoc
slightly (distinguishing the header from the beginning of the
documentation) improves the
>The inconsistency with style across different files is sad
Yep. And to be clear I am not against an effort to unify the file style.
Two tests attached as the following:
(this is the test that replace the blank line with random string, and
spotless just throw exception)
$git diff
diff --git
>has one blank line after copyright
Beam seems to have mixed style as well:
blank line before "package":
https://github.com/apache/beam/blob/166c6de33f2491c4c9bd27511cc71e33f8d2a894/buildSrc/src/main/groovy/org/apache/beam/gradle/GrpcVendoring.groovy#L18
no blank before "package":
In Apache Beam we actually using the style you mentioned: package-info.java
has one blank line after copyright.
I did a test. It turns out Spotless think it's a violation if there are
more than one blank line. Spotless can also fix it by deleting extra blank
lines and keep only one line. Another
After looking at Hive implementation I have the impression that it doesn't
use Apache Calcite for physical planning, hence it doesn't have the
problems mentioned in this topic.
вс, 8 дек. 2019 г. в 18:55, Vladimir Ozerov :
> Hi Stamatis,
>
> Thank you for the idea about Hive. I looked at it some
Hi,
I've noticed that package-info.java files have different copyright
"formatting" than all the other Java files.
The difference is as follows: package-info.java has a blank line after the
copyright, and all the other files do not have that blank line.
Sample blank like:
22 matches
Mail list logo
