[jira] [Created] (CALCITE-4905) JdbcCalc does not implement Calc
Francesco Gini created CALCITE-4905:
---
Summary: JdbcCalc does not implement Calc
Key: CALCITE-4905
URL: https://issues.apache.org/jira/browse/CALCITE-4905
Project: Calcite
Issue Type: Bug
Reporter: Francesco Gini
`JdbcCalc` class does not implement Calc. Failing to do that means that `
RelToSqlConverter` cannot translate a plan with `JdbcCalc` into sql because
`RelToSqlConverter` expects
```
{color:#cc7832}public {color}Result {color:#ffc66d}visit{color}(Calc e)
```
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
JIRA contributor permission
Hi, I would like to assign https://issues.apache.org/jira/browse/CALCITE-4905 to myself. Can I be registered in JIRA as a contributor, please ? My JIRA username is ggigio Cheers -- Francesco Gini
Re: JIRA contributor permission
Hey Francesco, I've added you as a contributor in Jira. Francis On 28/11/2021 10:09 pm, Francesco Gini wrote: Hi, I would like to assign https://issues.apache.org/jira/browse/CALCITE-4905 to myself. Can I be registered in JIRA as a contributor, please ? My JIRA username is ggigio Cheers
[jira] [Created] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
Aleksey Plekhanov created CALCITE-4906:
--
Summary: Wrong result for scalar subquery (single value
aggregation) from empty input
Key: CALCITE-4906
URL: https://issues.apache.org/jira/browse/CALCITE-4906
Project: Calcite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Scalar subqueries from the empty input return non-nullable type and in some
cases it leads to wrong results. For example:
{noformat}
SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
{noformat}
Returns {{0}}, but expected {{NULL}} according to the SQL standard:
{noformat}
Let SS be a .
Case:
a) If the cardinality of SS is greater than 1 (one), then an exception
condition is raised: cardinality violation.
b) If the cardinality of SS is 0 (zero), then the value of the is the null value.
c) Otherwise, let C be the column of simply contained in SS.
The value of SS is the value of C in the unique row of the result of the
.
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
Contributor role request
Hello, community! I'd like to contribute to Apache Calcite. I've created the ticket [1] and already have a patch for it, but can't assign the ticket to myself. Could you please add me to the contributor role? My JIRA account is alex_pl. [1]: https://issues.apache.org/jira/browse/CALCITE-4906
Re: [DISCUSS] Upgrading Elasticsearch in Calcite from 7.0.1 to 7.15
Hi, Julian, Andrei. I’ve upgraded the embedded Elasticsearch version to 7.15.2, so does the RestClient, and all the existing tests could run through. But when I try new ES features in unit test(such as multi_terms、top_metrics), results show that they are not available(cannot be parsed). I’ve also installed ES 7.15.2 locally, and I can get correct results with the above new features by running client codes, which are the same with the codes in calcite. So I’m wandering if I missed something necessary. It will be very helpful if you guys have some suggestions or directions. Best, Zhe Hu On 11/23/2021 09:08，Zhe Hu wrote： That’s very helpful, thanks for your reminder. I will look into whether ES rest client is backward compatible. On 11/23/2021 07:34，Andrei Sereda wrote： +1 Also take a look at vendor's official support schedule: https://www.elastic.co/support/eol I think it is safe to upgrade ES rest client to currently supported version. On Mon, Nov 22, 2021, 19:00 Julian Hyde wrote: +1 Sounds like a good idea. On Nov 22, 2021, at 6:40 AM, Zhe Hu wrote: Hi, community. Recently, when I tried to fix bugs in Elasticsearch Adapter, I’ve found that some new features in released Elasticsearch cannot be applied in Calcite, since the Elasticsearch version in Calcite is 7.0.1. For instance, as CALCITE-4868 mentioned, I want to sort aggregation results by multi_terms(supported after ES 7.1.11) as it’s more suitable under such circumstances than terms aggregation, however the DSL is not supported in Calcite currently. Moreover, I've browsed Elasticsearch's release notes roughly, and there are many new SQL features were added from 7.0.1 to 7.15.2, and lots of bugs were fixed meanwhile(if needed, I will spend some time to collect such info that benefits Calcite users). Since we use RestClient in Elasticsearch Adapter, there are still some cons about upgrading ES version, like new DSL couldn’t be used in old version Elasticsearch cluster, current use case might need to be adjusted. Nevertheless, I’m still wondering if we can upgrade the Elasticsearch version to 7.15, which could enrich ES Adapter's ablility as much as possible. Best regards, Zhe Hu
[DISCUSS] JIRA vs GitHub Issues
Hi, What do you think of moving to GitHub Issues for Calcite? Currently, my (Calcite) development workflow focuses on pull requests. That is all contributions I see come via pull requests. At the same time, issues are hosted in JIRA, which creates friction: PR merging requires changes to both GitHub and JIRA. I guess it would be easier if issue management was in GitHub as well. Then, I believe, co-locating issues and PRs would make external contributions easier. The links between Issues and PRs would be easier to navigate. There's a possibility to enable GitHub discussions as well (see https://github.com/apache/airflow/discussions ). Co-locating Issues, and Discussions look promising. I think it is not that painful, however, GitHub has a limitation of 20 collaborators (non-committers who want to assign, edit, close issues, and pull requests): https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub I have no strong opinion, however, I just realized having issues in GitHub would ease friction. Any thoughts? Just to gather opinion: -1..+1 keep using ASF JIRA for issue management -1..+1 migrate to GitHub Issues Here's my vote: +0.5 keep using ASF JIRA for issue management. It more-or-less works, however, merging PRs and navigating from PR to issue is far from perfect. +1 migrate to GitHub Issues. It would simplify navigation between issues and PRs, and I believe it would reduce friction for external contributors. In theory, GitHub Issues can be automated with Actions (e.g. labels). I'm not sure if we need that, however, it might be useful. Vladimir
[jira] [Created] (CALCITE-4907) JdbcJoin does not convert Join with alwayt true/false RexNode
Francesco Gini created CALCITE-4907: --- Summary: JdbcJoin does not convert Join with alwayt true/false RexNode Key: CALCITE-4907 URL: https://issues.apache.org/jira/browse/CALCITE-4907 Project: Calcite Issue Type: Bug Components: jdbc-adapter Affects Versions: 1.28.0 Reporter: Francesco Gini Assignee: Francesco Gini JdbcJoin does not handle cases where the condtion is a RexNode that it is always true or false. However, SqlImplementor is coded to handle those conditions (see SqlImplementor.convertConditionToSqlNode). Specifically a cross join is internally represented as a LogicalJoin with condition true which is not pushed down into the db. -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Contributor role request
Hey Alex, I've added you as a contributor in Jira. Francis On 29/11/2021 1:32 am, Alex Plehanov wrote: Hello, community! I'd like to contribute to Apache Calcite. I've created the ticket [1] and already have a patch for it, but can't assign the ticket to myself. Could you please add me to the contributor role? My JIRA account is alex_pl. [1]: https://issues.apache.org/jira/browse/CALCITE-4906
Please review the PR
Hi community, Please help review the pr https://github.com/apache/calcite/pull/2606, thanks a lot. CALCITE-4865 is the first sub-task of CALCITE-4864. This Jira aims to extend existing Table function in order to support Polymorphic Table Function which is introduced as the part of ANSI SQL 2016. The brief change logs of the PR are: - Update `Parser.jj` to support partition by clause and order by clause for input table with set semantics of PTF - Introduce `TableCharacteristics` which contains three characteristics of input table of table function - Update `SqlTableFunction` to add a method `tableCharacteristics`, the method returns the table characteristics for the ordinal-th argument to this table function. Default return value is Optional.empty which means the ordinal-th argument is not table. - Introduce `SqlSetSemanticsTable` which represents input table with set semantics of Table Function, its `SqlKind` is `SET_SEMANTICS_TABLE` - Updates `SqlValidatorImpl` to validate only set semantic table of Table Function could have partition by and order by clause - Update `SqlToRelConverter#substituteSubQuery` to parse subQuery which represents set semantics table. PR: https://github.com/apache/calcite/pull/2606 JIRA: https://issues.apache.org/jira/browse/CALCITE-4865 Parent JARA: https://issues.apache.org/jira/browse/CALCITE-4864 Best, Jing Zhang
Re:[DISCUSS] JIRA vs GitHub Issues
+0.5 As you mentioned, "co-locating issues and PRs would make external contributions easier”, I do agree with it. What’s more, when people browse this Project, they could have a basic picture about the latest progress more intuitive. But I also have some doubts about this migration. How do we process the existing issues in JIRA? Moving all of them to Github or just the open issues? Best, Zhe Hu On 11/29/2021 00:43，Vladimir Sitnikov wrote： Hi, What do you think of moving to GitHub Issues for Calcite? Currently, my (Calcite) development workflow focuses on pull requests. That is all contributions I see come via pull requests. At the same time, issues are hosted in JIRA, which creates friction: PR merging requires changes to both GitHub and JIRA. I guess it would be easier if issue management was in GitHub as well. Then, I believe, co-locating issues and PRs would make external contributions easier. The links between Issues and PRs would be easier to navigate. There's a possibility to enable GitHub discussions as well (see https://github.com/apache/airflow/discussions ). Co-locating Issues, and Discussions look promising. I think it is not that painful, however, GitHub has a limitation of 20 collaborators (non-committers who want to assign, edit, close issues, and pull requests): https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub I have no strong opinion, however, I just realized having issues in GitHub would ease friction. Any thoughts? Just to gather opinion: -1..+1 keep using ASF JIRA for issue management -1..+1 migrate to GitHub Issues Here's my vote: +0.5 keep using ASF JIRA for issue management. It more-or-less works, however, merging PRs and navigating from PR to issue is far from perfect. +1 migrate to GitHub Issues. It would simplify navigation between issues and PRs, and I believe it would reduce friction for external contributors. In theory, GitHub Issues can be automated with Actions (e.g. labels). I'm not sure if we need that, however, it might be useful. Vladimir
Re: Contributor role request
Hello Francis, Thank you! пн, 29 нояб. 2021 г. в 00:11, Francis Chuang : > Hey Alex, > > I've added you as a contributor in Jira. > > Francis > > On 29/11/2021 1:32 am, Alex Plehanov wrote: > > Hello, community! > > > > I'd like to contribute to Apache Calcite. I've created the ticket [1] and > > already have a patch for it, but can't assign the ticket to myself. > > Could you please add me to the contributor role? My JIRA account is > > alex_pl. > > > > [1]: https://issues.apache.org/jira/browse/CALCITE-4906 > > >
Re: [DISCUSS] JIRA vs GitHub Issues
We can copy all the issues, including resolved ones. We can import issues. GitHub has api for importing without notifications. Infra team can execute such a script (we need to find it) Vladimir
Re: [DISCUSS] JIRA vs GitHub Issues
Hi Vladimir, Thanks a lot for driving this discussion. + 0.5 1. First, I have same concern with @Zhe, how to deal with the existing issues. If there already exists tools to import these issue, I'm OK with that. 2. There are some useful functions in JIRA, I would list my favorite functions, I'm not sure whether github issue tracking could support these features. 1. Mark the fix versions of each JIRA issue. It is visible for users to find which version contain this functionality or fix this bug. 2. Watch the interested issue so I could receive email once this issue has been changed. 3. Relate the current JIRA issue with it's related JIRA. It is useful for other developers or users to understand this story. 3. JIRA is intuitive and friendly to non-technical people and new technical users. From my experience in Apache Flink community, this point is very useful because most of bug issues are reported by users instead of developer. Best, Jing Zhang Vladimir Sitnikov 于2021年11月29日周一 下午2:39写道： > We can copy all the issues, including resolved ones. > > We can import issues. GitHub has api for importing without notifications. > Infra team can execute such a script (we need to find it) > > Vladimir >
