Re: Calcite PR CI offten failed due to elasticsearch:test
Hello, I'll take a look at failing tests. It seems that embedded ES doesn't start correctly. Andrei. On Thu, Jul 9, 2020 at 10:21 PM JiaTao Tao wrote: > another case > https://travis-ci.org/github/apache/calcite/jobs/706573803 > > FAILURE 0.0sec, org.apache.calcite.test.RelMetadataTest > > testPullUpPredicatesFromUnion2() > java.lang.AssertionError: > Expected: "[=($0, 1), OR(AND(=($1, 2), =($2, 3)), =($1, 4))]" > but: was "[=($0, 1), OR(AND(=($2, 3), =($1, 2)), =($1, 4))]" > > Regards! > > Aron Tao > > > JiaTao Tao 于2020年7月9日周四 下午2:46写道： > > > Hi Stamatis Zampetakis > > > > I agree with you, on my local test, it is never failing, seems only a PR > > CI problem. > > Do you have any idea about disabling the tests only in PR CI? > > > > Regards! > > > > Aron Tao > > > > > > Stamatis Zampetakis 于2020年7月2日周四 下午5:05写道： > > > >> I didn't observe the problem on my local post so if it is only a CI > >> problem > >> then it would be nice if we could disable the tests only there. > >> > >> Best, > >> Stamatis > >> > >> On Thu, Jul 2, 2020 at 5:58 AM JiaTao Tao wrote: > >> > >> > Ok, thanks for your suggestion. I'll open a JIRA and track the status. > >> > > >> > > >> > Regards! > >> > > >> > Aron Tao > >> > > >> > > >> > Danny Chan 于2020年7月2日周四 上午11:37写道： > >> > > >> > > 2 and 3 doesn’t really solve the problem, I would choose 1, you > should > >> > log > >> > > these tests in the issue in order to track the status ~ > >> > > > >> > > Best, > >> > > Danny Chan > >> > > 在 2020年7月2日 +0800 AM11:15，JiaTao Tao ，写道： > >> > > > Hi Danny > >> > > > > >> > > > > >> > > > There is 4 failed ut, and the root cause is java.net > >> > > .SocketTimeoutException: > >> > > > 30,000 milliseconds timeout on connection http-outgoing-2 : > >> > > > > >> > > > elasticsearch.MatchTest > initializationError > >> > > > elasticsearch.BooleanLogicTest > initializationError > >> > > > elasticsearch.AggregationTest > initializationError > >> > > > elasticsearch.ProjectionTest > initializationError > >> > > > > >> > > > Here come the 3 solutions, hope to hear your advice. > >> > > > 1. Disable these UTs > >> > > > 2. Increase the timeout > >> > > > 3. Mark these UTs as slow tests > >> > > > > >> > > > > >> > > > Regards! > >> > > > > >> > > > Aron Tao > >> > > > > >> > > > > >> > > > Danny Chan 于2020年6月28日周日 上午10:01写道： > >> > > > > >> > > > > Yes, it times out often, can you log an issue there and disable > >> the > >> > > case ? > >> > > > > > >> > > > > Best, > >> > > > > Danny Chan > >> > > > > 在 2020年6月26日 +0800 PM6:00，JiaTao Tao ，写道： > >> > > > > > Seems an unstable case. > >> > > > > > > >> > > > > > > >> > > > > > Regards! > >> > > > > > > >> > > > > > Aron Tao > >> > > > > > >> > > > >> > > >> > > >
[jira] [Created] (CALCITE-4118) RexSimplify might remove CAST from RexNode incorrectly
Shuo Cheng created CALCITE-4118:
---
Summary: RexSimplify might remove CAST from RexNode incorrectly
Key: CALCITE-4118
URL: https://issues.apache.org/jira/browse/CALCITE-4118
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.23.0
Reporter: Shuo Cheng
Fix For: 1.24.0
{code:java}
@Test void testCastError() {
final String sql = "select cast(cast(count(distinct empno) as varchar(65536))
as varbinary)\n"
+ "from emp group by deptno";
sql(sql).ok();
}
{code}
Consider the above test case, we get the following plan after SqlToRel.
{code:java}
LogicalProject(EXPR$0=[CAST($1):VARBINARY NOT NULL])
LogicalAggregate(group=[{0}], agg#0=[COUNT(DISTINCT $1)])
LogicalProject(DEPTNO=[$7], EMPNO=[$0])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
As it is shown, `cast(* as varchar)` is removed (by RexSimplify#SimplifyCast),
which is obviously wrong, because BIGINT can not cast to VARBINARY.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Calcite PR CI offten failed due to elasticsearch:test
another case https://travis-ci.org/github/apache/calcite/jobs/706573803 FAILURE 0.0sec, org.apache.calcite.test.RelMetadataTest > testPullUpPredicatesFromUnion2() java.lang.AssertionError: Expected: "[=($0, 1), OR(AND(=($1, 2), =($2, 3)), =($1, 4))]" but: was "[=($0, 1), OR(AND(=($2, 3), =($1, 2)), =($1, 4))]" Regards! Aron Tao JiaTao Tao 于2020年7月9日周四 下午2:46写道： > Hi Stamatis Zampetakis > > I agree with you, on my local test, it is never failing, seems only a PR > CI problem. > Do you have any idea about disabling the tests only in PR CI? > > Regards! > > Aron Tao > > > Stamatis Zampetakis 于2020年7月2日周四 下午5:05写道： > >> I didn't observe the problem on my local post so if it is only a CI >> problem >> then it would be nice if we could disable the tests only there. >> >> Best, >> Stamatis >> >> On Thu, Jul 2, 2020 at 5:58 AM JiaTao Tao wrote: >> >> > Ok, thanks for your suggestion. I'll open a JIRA and track the status. >> > >> > >> > Regards! >> > >> > Aron Tao >> > >> > >> > Danny Chan 于2020年7月2日周四 上午11:37写道： >> > >> > > 2 and 3 doesn’t really solve the problem, I would choose 1, you should >> > log >> > > these tests in the issue in order to track the status ~ >> > > >> > > Best, >> > > Danny Chan >> > > 在 2020年7月2日 +0800 AM11:15，JiaTao Tao ，写道： >> > > > Hi Danny >> > > > >> > > > >> > > > There is 4 failed ut, and the root cause is java.net >> > > .SocketTimeoutException: >> > > > 30,000 milliseconds timeout on connection http-outgoing-2 : >> > > > >> > > > elasticsearch.MatchTest > initializationError >> > > > elasticsearch.BooleanLogicTest > initializationError >> > > > elasticsearch.AggregationTest > initializationError >> > > > elasticsearch.ProjectionTest > initializationError >> > > > >> > > > Here come the 3 solutions, hope to hear your advice. >> > > > 1. Disable these UTs >> > > > 2. Increase the timeout >> > > > 3. Mark these UTs as slow tests >> > > > >> > > > >> > > > Regards! >> > > > >> > > > Aron Tao >> > > > >> > > > >> > > > Danny Chan 于2020年6月28日周日 上午10:01写道： >> > > > >> > > > > Yes, it times out often, can you log an issue there and disable >> the >> > > case ? >> > > > > >> > > > > Best, >> > > > > Danny Chan >> > > > > 在 2020年6月26日 +0800 PM6:00，JiaTao Tao ，写道： >> > > > > > Seems an unstable case. >> > > > > > >> > > > > > >> > > > > > Regards! >> > > > > > >> > > > > > Aron Tao >> > > > > >> > > >> > >> >
Re: [DISCUSS] Towards Calcite 1.24.0
We have 174 open PRs. Quite a few of these are high-quality and ready
to go in, and they are not from committers, so they don't stand a
chance unless a committer takes the time to look at them. New
contributors will become demoralized if they do good work and it is
never looked at.
In the next 5 days, could every committer review one or two PRs, and
merge it to master if it is ready? You would be doing your part to
keep our community healthy and growing.
Julian
On Thu, Jul 9, 2020 at 11:26 AM Julian Hyde wrote:
>
> Chunwei,
>
> Thanks for kicking this off. RC on 7/14 sounds good.
>
> I have logged https://issues.apache.org/jira/browse/CALCITE-4117
> ("Release Calcite 1.24.0") and assigned it to you. I have a couple of
> bugs that I want to make depend on it (i.e. they can only be fixed
> AFTER 1.24).
>
> On Wed, Jul 8, 2020 at 11:25 PM Chunwei Lei wrote:
> >
> > Hi all,
> >
> > Approximately one and a half months have passed from the previous release
> > (Calcite
> > 1.23.0) and I was thinking that it would be nice to have the next release
> > around the 20
> > of July, considering there are already ~70 commits and some commits of
> > pull#2024[1]
> > to be merged after 1.24 is large and easy to be broken. To do this I think
> > we should try
> > to have an RC around the 14 of July.
> >
> > The progress towards the next release can be seen in [2]. As you can see,
> > we have 10
> > issues marked for fixing in 1.24.0. I suggest we focus on solving these
> > issues in the
> > following days. Apart from these issues, if you really think other issues
> > should be fixed
> > in 1.24.0, please comment in this thread and set the fix version to 1.24.0.
> >
> > Don't hesitate to reply to this thread if the plan above is not convenient
> > for you!
> >
> > [1] https://github.com/apache/calcite/pull/2024
> > [2]
> > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> >
> >
> > Best,
> > Chunwei
Re: [DISCUSS] Towards Calcite 1.24.0
Thanks Chunwei,
I am actively working on getting CALCITE-4000 and CALCITE-4015 reviewed and
merged by next week.
Question: are you planning to follow the practice of the last release (i.e.
lock master branch and clean up JIRA with fix version 1.24.0 marked before
re-open master branch?)
-Rui
On Thu, Jul 9, 2020 at 11:26 AM Julian Hyde wrote:
> Chunwei,
>
> Thanks for kicking this off. RC on 7/14 sounds good.
>
> I have logged https://issues.apache.org/jira/browse/CALCITE-4117
> ("Release Calcite 1.24.0") and assigned it to you. I have a couple of
> bugs that I want to make depend on it (i.e. they can only be fixed
> AFTER 1.24).
>
> On Wed, Jul 8, 2020 at 11:25 PM Chunwei Lei
> wrote:
> >
> > Hi all,
> >
> > Approximately one and a half months have passed from the previous release
> > (Calcite
> > 1.23.0) and I was thinking that it would be nice to have the next release
> > around the 20
> > of July, considering there are already ~70 commits and some commits of
> > pull#2024[1]
> > to be merged after 1.24 is large and easy to be broken. To do this I
> think
> > we should try
> > to have an RC around the 14 of July.
> >
> > The progress towards the next release can be seen in [2]. As you can see,
> > we have 10
> > issues marked for fixing in 1.24.0. I suggest we focus on solving these
> > issues in the
> > following days. Apart from these issues, if you really think other issues
> > should be fixed
> > in 1.24.0, please comment in this thread and set the fix version to
> 1.24.0.
> >
> > Don't hesitate to reply to this thread if the plan above is not
> convenient
> > for you!
> >
> > [1] https://github.com/apache/calcite/pull/2024
> > [2]
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> >
> >
> > Best,
> > Chunwei
>
Re: [DISCUSS] Towards Calcite 1.24.0
Chunwei,
Thanks for kicking this off. RC on 7/14 sounds good.
I have logged https://issues.apache.org/jira/browse/CALCITE-4117
("Release Calcite 1.24.0") and assigned it to you. I have a couple of
bugs that I want to make depend on it (i.e. they can only be fixed
AFTER 1.24).
On Wed, Jul 8, 2020 at 11:25 PM Chunwei Lei wrote:
>
> Hi all,
>
> Approximately one and a half months have passed from the previous release
> (Calcite
> 1.23.0) and I was thinking that it would be nice to have the next release
> around the 20
> of July, considering there are already ~70 commits and some commits of
> pull#2024[1]
> to be merged after 1.24 is large and easy to be broken. To do this I think
> we should try
> to have an RC around the 14 of July.
>
> The progress towards the next release can be seen in [2]. As you can see,
> we have 10
> issues marked for fixing in 1.24.0. I suggest we focus on solving these
> issues in the
> following days. Apart from these issues, if you really think other issues
> should be fixed
> in 1.24.0, please comment in this thread and set the fix version to 1.24.0.
>
> Don't hesitate to reply to this thread if the plan above is not convenient
> for you!
>
> [1] https://github.com/apache/calcite/pull/2024
> [2]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>
>
> Best,
> Chunwei
[jira] [Created] (CALCITE-4117) Release Calcite 1.24.0
Julian Hyde created CALCITE-4117: Summary: Release Calcite 1.24.0 Key: CALCITE-4117 URL: https://issues.apache.org/jira/browse/CALCITE-4117 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Chunwei Lei Fix For: 1.24.0 Release Calcite 1.24.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4116) Remove unused code for tracking RexNode's nullable state in codegen
Feng Zhu created CALCITE-4116: - Summary: Remove unused code for tracking RexNode's nullable state in codegen Key: CALCITE-4116 URL: https://issues.apache.org/jira/browse/CALCITE-4116 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.23.0 Reporter: Feng Zhu Assignee: Feng Zhu The PR in CALCITE-3224 takes RexNode's nullable state as immutable during codegen. Since it has been merged, we can safely remove unused code that changes and tracks RexNode's nullable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4115) Improve the prompt of using SQL keywords for sql parser
Danny Chen created CALCITE-4115:
---
Summary: Improve the prompt of using SQL keywords for sql parser
Key: CALCITE-4115
URL: https://issues.apache.org/jira/browse/CALCITE-4115
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.23.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.24.0
Current when a user uses a reserved-keyword in the SQL, for example:
{code:sql}
select DEFAULT from emp;
{code}
the parser would report with error message:
{noformat}
Encountered "DEFAULT" at line 1, column 8.
Was expecting one of:
"ABS" ...
"ALL" ...
"ARRAY" ...
"AVG" ...
"CARDINALITY" ...
"CASE" ...
"CAST" ...
"CEIL" ...
"CEILING" ...
"CHAR_LENGTH" ...
"CHARACTER_LENGTH" ...
{noformat}
It is hard to infer that the DEFAULT is actually a reserved-keyword, we can
promote the message to make it more clear.
For example, in SQL-SERVER, if you use such a keyword, the server reports
"Incorrect syntax near the keyword 'DEFAULT'", which is very clear that the
DEFAULT is a keyword.
Based on the SQL-SERVER message, i would suggest to also report the position
with a suggested fix solution, the template is like this:
{code:java}
Incorrect syntax near the keyword {keyword} at line {line_number},
column {column_number}.\n
Either uses a non-reserved keyword or quotes the keyword with
character: {quoting_character}.
{code}
We would tell user that the mistake is a keyword and its position, also how to
fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Calcite PR CI offten failed due to elasticsearch:test
Hi Stamatis Zampetakis I agree with you, on my local test, it is never failing, seems only a PR CI problem. Do you have any idea about disabling the tests only in PR CI? Regards! Aron Tao Stamatis Zampetakis 于2020年7月2日周四 下午5:05写道： > I didn't observe the problem on my local post so if it is only a CI problem > then it would be nice if we could disable the tests only there. > > Best, > Stamatis > > On Thu, Jul 2, 2020 at 5:58 AM JiaTao Tao wrote: > > > Ok, thanks for your suggestion. I'll open a JIRA and track the status. > > > > > > Regards! > > > > Aron Tao > > > > > > Danny Chan 于2020年7月2日周四 上午11:37写道： > > > > > 2 and 3 doesn’t really solve the problem, I would choose 1, you should > > log > > > these tests in the issue in order to track the status ~ > > > > > > Best, > > > Danny Chan > > > 在 2020年7月2日 +0800 AM11:15，JiaTao Tao ，写道： > > > > Hi Danny > > > > > > > > > > > > There is 4 failed ut, and the root cause is java.net > > > .SocketTimeoutException: > > > > 30,000 milliseconds timeout on connection http-outgoing-2 : > > > > > > > > elasticsearch.MatchTest > initializationError > > > > elasticsearch.BooleanLogicTest > initializationError > > > > elasticsearch.AggregationTest > initializationError > > > > elasticsearch.ProjectionTest > initializationError > > > > > > > > Here come the 3 solutions, hope to hear your advice. > > > > 1. Disable these UTs > > > > 2. Increase the timeout > > > > 3. Mark these UTs as slow tests > > > > > > > > > > > > Regards! > > > > > > > > Aron Tao > > > > > > > > > > > > Danny Chan 于2020年6月28日周日 上午10:01写道： > > > > > > > > > Yes, it times out often, can you log an issue there and disable the > > > case ? > > > > > > > > > > Best, > > > > > Danny Chan > > > > > 在 2020年6月26日 +0800 PM6:00，JiaTao Tao ，写道： > > > > > > Seems an unstable case. > > > > > > > > > > > > > > > > > > Regards! > > > > > > > > > > > > Aron Tao > > > > > > > > > > >
Re: Calcite PR CI offten failed due to elasticsearch:test
Hi I've disabled related tests and observed the PR for a few days, seems there's no more unstable failures. If anyone finds it comes again, please let me know. Regards! Aron Tao Stamatis Zampetakis 于2020年7月2日周四 下午5:05写道： > I didn't observe the problem on my local post so if it is only a CI problem > then it would be nice if we could disable the tests only there. > > Best, > Stamatis > > On Thu, Jul 2, 2020 at 5:58 AM JiaTao Tao wrote: > > > Ok, thanks for your suggestion. I'll open a JIRA and track the status. > > > > > > Regards! > > > > Aron Tao > > > > > > Danny Chan 于2020年7月2日周四 上午11:37写道： > > > > > 2 and 3 doesn’t really solve the problem, I would choose 1, you should > > log > > > these tests in the issue in order to track the status ~ > > > > > > Best, > > > Danny Chan > > > 在 2020年7月2日 +0800 AM11:15，JiaTao Tao ，写道： > > > > Hi Danny > > > > > > > > > > > > There is 4 failed ut, and the root cause is java.net > > > .SocketTimeoutException: > > > > 30,000 milliseconds timeout on connection http-outgoing-2 : > > > > > > > > elasticsearch.MatchTest > initializationError > > > > elasticsearch.BooleanLogicTest > initializationError > > > > elasticsearch.AggregationTest > initializationError > > > > elasticsearch.ProjectionTest > initializationError > > > > > > > > Here come the 3 solutions, hope to hear your advice. > > > > 1. Disable these UTs > > > > 2. Increase the timeout > > > > 3. Mark these UTs as slow tests > > > > > > > > > > > > Regards! > > > > > > > > Aron Tao > > > > > > > > > > > > Danny Chan 于2020年6月28日周日 上午10:01写道： > > > > > > > > > Yes, it times out often, can you log an issue there and disable the > > > case ? > > > > > > > > > > Best, > > > > > Danny Chan > > > > > 在 2020年6月26日 +0800 PM6:00，JiaTao Tao ，写道： > > > > > > Seems an unstable case. > > > > > > > > > > > > > > > > > > Regards! > > > > > > > > > > > > Aron Tao > > > > > > > > > > >
[jira] [Created] (CALCITE-4114) Wrong name in AssertQuery#forceDecorrelate
Jiatao Tao created CALCITE-4114:
---
Summary: Wrong name in AssertQuery#forceDecorrelate
Key: CALCITE-4114
URL: https://issues.apache.org/jira/browse/CALCITE-4114
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Jiatao Tao
Assignee: Jiatao Tao
Attachments: image-2020-07-09-14-34-52-644.png
The description is: "Creates a \{@link FrameworkConfig} that does not
decorrelate.", and the body is set CalciteConnectionProperty.FORCE_DECORRELATE
to false.
But the function name is forceDecorrelate, quite confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[DISCUSS] Towards Calcite 1.24.0
Hi all, Approximately one and a half months have passed from the previous release (Calcite 1.23.0) and I was thinking that it would be nice to have the next release around the 20 of July, considering there are already ~70 commits and some commits of pull#2024[1] to be merged after 1.24 is large and easy to be broken. To do this I think we should try to have an RC around the 14 of July. The progress towards the next release can be seen in [2]. As you can see, we have 10 issues marked for fixing in 1.24.0. I suggest we focus on solving these issues in the following days. Apart from these issues, if you really think other issues should be fixed in 1.24.0, please comment in this thread and set the fix version to 1.24.0. Don't hesitate to reply to this thread if the plan above is not convenient for you! [1] https://github.com/apache/calcite/pull/2024 [2] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 Best, Chunwei
