My plan is to get automated site builds up and running first, which
should get rid of the most difficult/troublesome steps for updating the
site.
We can then evolve/experiment with the site to improve the process further.
On 12/12/2019 6:28 pm, Stamatis Zampetakis wrote:
I guess it will requi
Hi Haisheng,
I am trying to model the proposal based on ideas from Cascades. This
assumes top-down control of the optimization process, i.e. the parent
drives optimization of the child. But as a result of this top-down
propagation of optimization requests, the implementation rules are applied
bott
In this commit, Vladimir brought to my attention that editors on Windows
will complain about line endings if there isn't a zip source release
with Windows line endings:
https://github.com/apache/calcite-avatica/commit/34bbcb63f9216d3a5bc29dae1981a55e335d30df#commitcomment-36393594
I don't real
Adapters must be needed by data sources not supporting SQL, I think this is
what Juan Pan was asking for.
On Thu, 12 Dec 2019 at 04:05, Haisheng Yuan wrote:
> Nope, it doesn't use any adapters. It just submits partial SQL query to
> different engines.
>
> If query contains table from single sour
Dear calcite developer community:
https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-3589. I am a
member of Apache Kylin and a user of Apache Calcitite,This issue was mentioned
by me, can i fix it by myself。
thanks
Ruben Q L created CALCITE-3598:
--
Summary: ClassCastException in MaterializationTest
testJoinMaterialization8 and testJoinMaterialization9
Key: CALCITE-3598
URL: https://issues.apache.org/jira/browse/CALCITE-3598
Hey,
I've added you as a contributor to the project and assigned you to the
issue. Please go ahead and open a PR on Github for review.
Francis
On 12/12/2019 9:43 pm, 过 冰峰 wrote:
Dear calcite developer community:
https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-3589. I am a
me
Thank you so much, I am very excited now, thank the apache calcite community
在 2019/12/12 下午7:30,“Francis Chuang” 写入:
Hey,
I've added you as a contributor to the project and assigned you to the
issue. Please go ahead and open a PR on Github for review.
Francis
I think a source distribution should contain the raw, unprocessed source files.
The contents of the .zip and .tar.gz should be identical.
If people want to change line endings they can do it for themselves. Or use an
appropriate git setting.
> On Dec 12, 2019, at 1:03 AM, Francis Chuang wro
>I think a source distribution should contain the raw, unprocessed source
files.
What do you mean by "raw"?
If I check out the same repository on Windows and macOS, I would get
**different** file contents for *.java files.
Windows machine would check out files as CRLF, and macOS would checkout th
Chunwei Lei created CALCITE-3599:
Summary: Initial the digest of RexRangeRef to avoid null string
Key: CALCITE-3599
URL: https://issues.apache.org/jira/browse/CALCITE-3599
Project: Calcite
Is
I agree with both points. The source code should be what unprocessed,
but since Windows and Linux/macOS users get different source code
anyway, I'm not opposed to having two archives with different line
endings. This is mostly unrelated, but at some point, I would be
interested in exploring produci
Michael>The source code should be what unprocessed,
Michael>but since Windows
I do not get what you mean by "unprocessed".
Even Maven build had lots of exclude-include patterns, so it did "process"
the sources.
Then, the current source release contains LICENSE file that contains some
processing (
Absolutely. Thanks lgor for the contribution! :)
-Rui
On Wed, Dec 11, 2019 at 10:54 PM Stamatis Zampetakis
wrote:
> So basically thanks to Igor :)
>
> On Wed, Dec 11, 2019 at 9:56 PM Rui Wang wrote:
>
> > Thanks Stamatis's suggestion. Indeed a recent effort in [1] enhanced the
> > support tha
The git repo, at a particular commit, has an objective contents. I suspect that
when you use ‘git checkout’ with particular options, you don’t get those
objective contents, you get something customized for your line-ending
preference.
> On Dec 12, 2019, at 7:46 AM, Vladimir Sitnikov
> wrote:
Julian>The git repo, at a particular commit, has an objective contents
That is true for binary blobs.
However, text files are converted on checkout as per core.autocrlf and
core.eol settings.
Julian>I suspect that when you use ‘git checkout’ with particular options
I suspect you are not very wel
Ubuntu 18.04.3 LTS, jdk1.8.0_202, 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 tests (./gradlew clean build) on staged sources OK
* Run build and Calcite tests on Calcite current mast
The main purpose of the source distribution is to have legal record of the
release, and something from which people could re-create the release if GitHub
and all mirrors thereof were to disappear.
For all other purpose, just use git.
So, I see no reason to create different source distributions
Julian>For all other purpose, just use git.
"use git" contradicts with
http://www.apache.org/legal/release-policy.html#publication
legal/release-policy> Projects MUST direct outsiders towards official
releases rather than raw source repositories, nightly builds, snapshots,
release candidates, or
No, I’m going to ignore this trolling.
> On Dec 12, 2019, at 11:57 AM, Vladimir Sitnikov
> wrote:
>
> Julian>For all other purpose, just use git.
>
> "use git" contradicts with
> http://www.apache.org/legal/release-policy.html#publication
>
> legal/release-policy> Projects MUST direct outside
anjali shrishrimal created CALCITE-3600:
---
Summary: Rule to solve the filter partially by end application and
remaining by calcite
Key: CALCITE-3600
URL: https://issues.apache.org/jira/browse/CALCITE-3600
Hi guys,
I made a PR and run continuous integration tests. [1]
A error test contained in the PR and tagged with @slowTest.
The tests should be failed but CI passed by mistake.
I doubt our current CI is not running with 'testSlow' configuration. Isn't
it ?
I'm not sure if I should create a JIRA.
Be
22 matches
Mail list logo