[jira] [Updated] (CALCITE-6165) Add DATE_ADD test and DATE_DIFF test on SqlOperatorTest
[ https://issues.apache.org/jira/browse/CALCITE-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caican Cai updated CALCITE-6165: Summary: Add DATE_ADD test and DATE_DIFF test on SqlOperatorTest (was: Add DATE_ADD and DATE_DIFF test on SqlOperatorTest) > Add DATE_ADD test and DATE_DIFF test on SqlOperatorTest > --- > > Key: CALCITE-6165 > URL: https://issues.apache.org/jira/browse/CALCITE-6165 > Project: Calcite > Issue Type: Test > Components: tests >Affects Versions: 1.36.0 >Reporter: Caican Cai >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: 2023-12-17 17-04-29屏幕截图-1.png, 2023-12-17 > 17-04-29屏幕截图.png > > > Missing tests for date_add and date_diff in SqlOperatorTest > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6165) Add DATE_ADD and DATE_DIFF test on SqlOperatorTest
[ https://issues.apache.org/jira/browse/CALCITE-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caican Cai updated CALCITE-6165: Summary: Add DATE_ADD and DATE_DIFF test on SqlOperatorTest (was: Add date_sub test and date_diff test on SqlOperatorTest) > Add DATE_ADD and DATE_DIFF test on SqlOperatorTest > -- > > Key: CALCITE-6165 > URL: https://issues.apache.org/jira/browse/CALCITE-6165 > Project: Calcite > Issue Type: Test > Components: tests >Affects Versions: 1.36.0 >Reporter: Caican Cai >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: 2023-12-17 17-04-29屏幕截图-1.png, 2023-12-17 > 17-04-29屏幕截图.png > > > Missing tests for date_add and date_diff in SqlOperatorTest > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6165) Add date_sub test and date_diff test on SqlOperatorTest
[ https://issues.apache.org/jira/browse/CALCITE-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799646#comment-17799646 ] Ran Tao commented on CALCITE-6165: -- I checked that date_sub, date_add, date_diff and other date functions are all described in reference.md, which means that you can just add SqlOperatorTest, but there are still some minor problems with PR, which may be fixed. > Add date_sub test and date_diff test on SqlOperatorTest > --- > > Key: CALCITE-6165 > URL: https://issues.apache.org/jira/browse/CALCITE-6165 > Project: Calcite > Issue Type: Test > Components: tests >Affects Versions: 1.36.0 >Reporter: Caican Cai >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: 2023-12-17 17-04-29屏幕截图-1.png, 2023-12-17 > 17-04-29屏幕截图.png > > > Missing tests for date_add and date_diff in SqlOperatorTest > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6174) Upgrade gradle to 8.5
[ https://issues.apache.org/jira/browse/CALCITE-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6174: Labels: pull-request-available (was: ) > Upgrade gradle to 8.5 > - > > Key: CALCITE-6174 > URL: https://issues.apache.org/jira/browse/CALCITE-6174 > Project: Calcite > Issue Type: Sub-task >Reporter: Sergey Nuyanzin >Priority: Major > Labels: pull-request-available > > Gradle 8.5 is the first fully supporting java 21 gradle based on docs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6174) Upgrade gradle to 8.5
Sergey Nuyanzin created CALCITE-6174: Summary: Upgrade gradle to 8.5 Key: CALCITE-6174 URL: https://issues.apache.org/jira/browse/CALCITE-6174 Project: Calcite Issue Type: Sub-task Reporter: Sergey Nuyanzin Gradle 8.5 is the first fully supporting java 21 gradle based on docs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6173) Support java 21
Sergey Nuyanzin created CALCITE-6173: Summary: Support java 21 Key: CALCITE-6173 URL: https://issues.apache.org/jira/browse/CALCITE-6173 Project: Calcite Issue Type: Improvement Reporter: Sergey Nuyanzin In case of Calcite it is a tricky task because of gradle upgrade from one side which also depends on kotlin and because of plenty of deprecations from another side for that reason I use this task as an umbrella -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799615#comment-17799615 ] Julian Hyde commented on CALCITE-6172: -- [~tanclary], You can easily answer the question 'What libraries support this function?' because the set of libraries is fixed. You can iterate over all libraries and ask each library whether it supports the function. > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799614#comment-17799614 ] Sergey Nuyanzin commented on CALCITE-6172: -- yep, feel free > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799613#comment-17799613 ] Tanner Clary commented on CALCITE-6172: --- [~Sergey Nuyanzin]This looks good, I can add it for the other tests and maybe touch up a couple things and then we can review? > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[
https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799612#comment-17799612
]
Sergey Nuyanzin commented on CALCITE-6172:
--
there could be a pojo which then could be passed to parameterized test
here it is a PoC of how it could look like for {{STARTS_WITH}}
https://github.com/apache/calcite/pull/3590
similar way it could be done for others
> Allow aliased operators to re-use existing tests
>
>
> Key: CALCITE-6172
> URL: https://issues.apache.org/jira/browse/CALCITE-6172
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Currently, for operators that have multiple names (potentially across
> multiple libraries), there is no convenient way to re-use tests other than
> just copy and pasting. To avoid redundancy and potential discrepancies, it
> would be helpful if the same set of tests could be used for each alias.
> I'll modify this case once I have some ideas.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6172: Labels: pull-request-available (was: ) > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-3522) Sql validator limits decimal literals to 64 bits
[ https://issues.apache.org/jira/browse/CALCITE-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3522: Labels: pull-request-available (was: ) > Sql validator limits decimal literals to 64 bits > > > Key: CALCITE-3522 > URL: https://issues.apache.org/jira/browse/CALCITE-3522 > Project: Calcite > Issue Type: Test > Components: core >Affects Versions: 1.18.0 >Reporter: Changbo Shu >Priority: Minor > Labels: pull-request-available > Attachments: code.png > > > [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2983] > for example: > create table tbl(f1 double), > f1 stores a double's max value. (1.7976931348623157E308) > long max value is 9223372036854775807. > select * from table where f1=value, if value is greater than long max, > sqlvalidator will throw out of range exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799603#comment-17799603 ] Tanner Clary edited comment on CALCITE-6172 at 12/21/23 11:00 PM: -- [~julianhyde][~Sergey Nuyanzin]Right now, you can access the operators that belong to an library, but not what libraries support a specified operator (to my knowledge). If we made this bidirectional then we could just provide a list of the operators and then the tests could be run against each operator, for each library. was (Author: JIRAUSER298151): [~julianhyde][~Sergey Nuyanzin]Right now, you can access the operators that belong to an library, but not what libraries support a specified library (to my knowledge). If we made this bidirectional then we could just provide a list of the operators and then the tests could be run against each operator, for each library. > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799603#comment-17799603 ] Tanner Clary commented on CALCITE-6172: --- [~julianhyde][~Sergey Nuyanzin]Right now, you can access the operators that belong to an library, but not what libraries support a specified library (to my knowledge). If we made this bidirectional then we could just provide a list of the operators and then the tests could be run against each operator, for each library. > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[
https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799599#comment-17799599
]
Tanner Clary commented on CALCITE-6172:
---
[~Sergey Nuyanzin]This sounds good. Do you know if this would play with the
SqlLibrary consumer some of the tests use?
For instance if you have Snowflake's {{STARTSWITH}} and BigQuery's
{{STARTS_WITH}}, is there a good way to make sure {{STARTSWITH}} gets ran with
Snowflake, etc.
> Allow aliased operators to re-use existing tests
>
>
> Key: CALCITE-6172
> URL: https://issues.apache.org/jira/browse/CALCITE-6172
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> Currently, for operators that have multiple names (potentially across
> multiple libraries), there is no convenient way to re-use tests other than
> just copy and pasting. To avoid redundancy and potential discrepancies, it
> would be helpful if the same set of tests could be used for each alias.
> I'll modify this case once I have some ideas.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[
https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799598#comment-17799598
]
Sergey Nuyanzin commented on CALCITE-6172:
--
As an idea: what if we use {{ParameterizedTest}} and a set of aliases as
parameter input for the test?
> Allow aliased operators to re-use existing tests
>
>
> Key: CALCITE-6172
> URL: https://issues.apache.org/jira/browse/CALCITE-6172
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> Currently, for operators that have multiple names (potentially across
> multiple libraries), there is no convenient way to re-use tests other than
> just copy and pasting. To avoid redundancy and potential discrepancies, it
> would be helpful if the same set of tests could be used for each alias.
> I'll modify this case once I have some ideas.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6156) Add ENDSWITH, STARTSWITH functions (enabled in Postgres, Snowflake libraries)
[
https://issues.apache.org/jira/browse/CALCITE-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799594#comment-17799594
]
Julian Hyde edited comment on CALCITE-6156 at 12/21/23 10:35 PM:
-
Merged via
[e74ff3ea|https://github.com/apache/calcite/commit/e74ff3eaa0a339ad3d099739780ce05a40efbe87],
thanks for the reviews, [~julianhyde] and [~jerin_john]!
was (Author: JIRAUSER298151):
Merged via
[e74ff3ea|https://github.com/apache/calcite/commit/e74ff3eaa0a339ad3d099739780ce05a40efbe87],
thanks for the reviews, [~julianhyde][~jerin_john]!
> Add ENDSWITH, STARTSWITH functions (enabled in Postgres, Snowflake libraries)
> -
>
> Key: CALCITE-6156
> URL: https://issues.apache.org/jira/browse/CALCITE-6156
> Project: Calcite
> Issue Type: New Feature
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Calcite already offers BigQuery's {{STARTS_WITH}} and {{ENDS_WITH}}
> functions. Postgres offers these functions as well. Snowflake offers two very
> similar functions (the only difference being the naming).
> Examples of each function can be found in their original implementation
> commit
> [742d477|https://github.com/apache/calcite/commit/742d47795b878576f8cbdab5f62b26d95559792a]
> There will also need to be a small change necessary since Snowflake uses
> {{ENDSWITH}} and {{STARTSWITH}} as the function names.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6172) Allow aliased operators to re-use existing tests
[
https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799597#comment-17799597
]
Julian Hyde commented on CALCITE-6172:
--
One particular test is {{SqlOperatorTest.java}}. In CALCITE-6156, which added
{{STARTSWITH}} as an alias for {{STARTS_WITH}}, about 25 lines were added which
were copy-pasted tests.
Functions that are aliases, according to {{StandardConvertletTable.java}}:
* {{ENDSWITH}}, {{ENDS_WITH}} - see CALCITE-6156
* {{STARTSWITH}}, {{STARTS_WITH}} - CALCITE-6156
* {{NVL}}, {{IFNULL}} - see CALCITE-5430
* {{<=>}}, {{IS NOT DISTINCT FROM}} - see CALCITE-5430
* {{IS UNKNOWN}}, {{IS NULL}}
* {{IS NOT UNKNOWN}}, {{IS NOT NULL}}
* {{LENGTH}}, {{CHAR_LENGTH}}, {{CHARACTER_LENGTH}} - see CALCITE-5452
* {{REGEXP_SUBSTR}}, {{REGEXP_EXTRACT}} - see CALCITE-5910
The goal is not to write zero tests - that way we would not notice if the alias
stopped working - but to reuse the majority of tests.
> Allow aliased operators to re-use existing tests
>
>
> Key: CALCITE-6172
> URL: https://issues.apache.org/jira/browse/CALCITE-6172
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> Currently, for operators that have multiple names (potentially across
> multiple libraries), there is no convenient way to re-use tests other than
> just copy and pasting. To avoid redundancy and potential discrepancies, it
> would be helpful if the same set of tests could be used for each alias.
> I'll modify this case once I have some ideas.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6156) Add ENDSWITH, STARTSWITH functions (enabled in Postgres, Snowflake libraries)
[
https://issues.apache.org/jira/browse/CALCITE-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-6156.
---
Fix Version/s: 1.37.0
Resolution: Fixed
Merged via
[e74ff3ea|https://github.com/apache/calcite/commit/e74ff3eaa0a339ad3d099739780ce05a40efbe87],
thanks for the reviews, [~julianhyde][~jerin_john]!
> Add ENDSWITH, STARTSWITH functions (enabled in Postgres, Snowflake libraries)
> -
>
> Key: CALCITE-6156
> URL: https://issues.apache.org/jira/browse/CALCITE-6156
> Project: Calcite
> Issue Type: New Feature
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Calcite already offers BigQuery's {{STARTS_WITH}} and {{ENDS_WITH}}
> functions. Postgres offers these functions as well. Snowflake offers two very
> similar functions (the only difference being the naming).
> Examples of each function can be found in their original implementation
> commit
> [742d477|https://github.com/apache/calcite/commit/742d47795b878576f8cbdab5f62b26d95559792a]
> There will also need to be a small change necessary since Snowflake uses
> {{ENDSWITH}} and {{STARTSWITH}} as the function names.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6172) Allow aliased operators to re-use existing tests
Tanner Clary created CALCITE-6172: - Summary: Allow aliased operators to re-use existing tests Key: CALCITE-6172 URL: https://issues.apache.org/jira/browse/CALCITE-6172 Project: Calcite Issue Type: Improvement Reporter: Tanner Clary Assignee: Tanner Clary Currently, for operators that have multiple names (potentially across multiple libraries), there is no convenient way to re-use tests other than just copy and pasting. To avoid redundancy and potential discrepancies, it would be helpful if the same set of tests could be used for each alias. I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[ https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799478#comment-17799478 ] Ulrich Kramer commented on CALCITE-4188: I also created a PR for this issue: https://github.com/apache/calcite/pull/3562 I had overlooked this ticket here. The main difference between the two PR is how correlation variable are handled: - 3562 uses an offset of 1 to put the correlation variables into the DataContext - 2116 uses an enum to distinguish between correlation variables and dynamic variables, which is the more robust way. > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > > > Key: CALCITE-4188 > URL: https://issues.apache.org/jira/browse/CALCITE-4188 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.25.0 >Reporter: JIasen Sheng >Priority: Major > Labels: pull-request-available > Time Spent: 2h > Remaining Estimate: 0h > > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > function > ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode, > when implementing, > [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675] > will throw null Exception -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5409) Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
[
https://issues.apache.org/jira/browse/CALCITE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799475#comment-17799475
]
Ulrich Kramer commented on CALCITE-5409:
Sorry for reopening this issue. It's really a duplicate of CALCITE-4188.
I will close this ticket and add my PR to CALCITE-4188.
> Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
> ---
>
> Key: CALCITE-5409
> URL: https://issues.apache.org/jira/browse/CALCITE-5409
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.33.0
>
>
> Adding the following unit test to {{JdbcAdapterTest}} causes an
> {{NullPointerException}}
> {code:java}
> @Test void testBatchNestedLoopJoin() {
> CalciteAssert.that()
> .with(CalciteConnectionProperty.LEX, Lex.JAVA)
> .with(CalciteConnectionProperty.FORCE_DECORRELATE, false)
> .withSchema("s", new ReflectiveSchema(new HrSchema()))
> .withModel(FoodmartSchema.FOODMART_MODEL)
> .query("select e.name from emps e join foodmart.store x on e.deptno =
> x.store_id")
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_CORRELATE_RULE);
>
> planner.addRule(EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE);
> })
> .runs();
> }
> {code}
> {code}
> Error while executing SQL "select e.name from emps e join foodmart.store x on
> e.deptno = x.store_id": Unable to implement
> EnumerableCalc(expr#0..2=[{inputs}], name=[$t0]): rowcount = 375.0,
> cumulative cost = {1465.0 rows, 2968.0 cpu, 0.0 io}, id = 174
> EnumerableBatchNestedLoopJoin(condition=[=($1, $2)], joinType=[inner],
> variablesSet=[[$cor0, ... $cor99]], batchSize=[100]): rowcount = 375.0,
> cumulative cost = {1090.0 rows, 1468.0 cpu, 0.0 io}, id = 170
> EnumerableCalc(expr#0..4=[{inputs}], expr#5=[CAST($t1):INTEGER NOT NULL],
> name=[$t2], deptno0=[$t5]): rowcount = 100.0, cumulative cost = {200.0 rows,
> 901.0 cpu, 0.0 io}, id = 176
> EnumerableTableScan(table=[[s, emps]]): rowcount = 100.0, cumulative
> cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 52
> JdbcToEnumerableConverter: rowcount = 25.0, cumulative cost = {207.5
> rows, 283.5 cpu, 0.0 io}, id = 168
> JdbcFilter(condition=[OR(=($cor0.deptno0, $0), ...)]): rowcount = 25.0,
> cumulative cost = {205.0 rows, 281.0 cpu, 0.0 io}, id = 166
> JdbcProject(store_id=[$0]): rowcount = 100.0, cumulative cost =
> {180.0 rows, 181.0 cpu, 0.0 io}, id = 164
> JdbcTableScan(table=[[foodmart, store]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 3
> ...
> Suppressed: java.lang.NullPointerException: variable $cor0 is not found
> {code}
> See also https://issues.apache.org/jira/browse/CALCITE-5354
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-5409) Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
[
https://issues.apache.org/jira/browse/CALCITE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich Kramer closed CALCITE-5409.
--
Resolution: Duplicate
> Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
> ---
>
> Key: CALCITE-5409
> URL: https://issues.apache.org/jira/browse/CALCITE-5409
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.33.0
>
>
> Adding the following unit test to {{JdbcAdapterTest}} causes an
> {{NullPointerException}}
> {code:java}
> @Test void testBatchNestedLoopJoin() {
> CalciteAssert.that()
> .with(CalciteConnectionProperty.LEX, Lex.JAVA)
> .with(CalciteConnectionProperty.FORCE_DECORRELATE, false)
> .withSchema("s", new ReflectiveSchema(new HrSchema()))
> .withModel(FoodmartSchema.FOODMART_MODEL)
> .query("select e.name from emps e join foodmart.store x on e.deptno =
> x.store_id")
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_CORRELATE_RULE);
>
> planner.addRule(EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE);
> })
> .runs();
> }
> {code}
> {code}
> Error while executing SQL "select e.name from emps e join foodmart.store x on
> e.deptno = x.store_id": Unable to implement
> EnumerableCalc(expr#0..2=[{inputs}], name=[$t0]): rowcount = 375.0,
> cumulative cost = {1465.0 rows, 2968.0 cpu, 0.0 io}, id = 174
> EnumerableBatchNestedLoopJoin(condition=[=($1, $2)], joinType=[inner],
> variablesSet=[[$cor0, ... $cor99]], batchSize=[100]): rowcount = 375.0,
> cumulative cost = {1090.0 rows, 1468.0 cpu, 0.0 io}, id = 170
> EnumerableCalc(expr#0..4=[{inputs}], expr#5=[CAST($t1):INTEGER NOT NULL],
> name=[$t2], deptno0=[$t5]): rowcount = 100.0, cumulative cost = {200.0 rows,
> 901.0 cpu, 0.0 io}, id = 176
> EnumerableTableScan(table=[[s, emps]]): rowcount = 100.0, cumulative
> cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 52
> JdbcToEnumerableConverter: rowcount = 25.0, cumulative cost = {207.5
> rows, 283.5 cpu, 0.0 io}, id = 168
> JdbcFilter(condition=[OR(=($cor0.deptno0, $0), ...)]): rowcount = 25.0,
> cumulative cost = {205.0 rows, 281.0 cpu, 0.0 io}, id = 166
> JdbcProject(store_id=[$0]): rowcount = 100.0, cumulative cost =
> {180.0 rows, 181.0 cpu, 0.0 io}, id = 164
> JdbcTableScan(table=[[foodmart, store]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 3
> ...
> Suppressed: java.lang.NullPointerException: variable $cor0 is not found
> {code}
> See also https://issues.apache.org/jira/browse/CALCITE-5354
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5409) Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
[
https://issues.apache.org/jira/browse/CALCITE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799471#comment-17799471
]
Stamatis Zampetakis commented on CALCITE-5409:
--
This was previously tagged as a duplicate of CALCITE-4188. The original ticket
had quite a bit of history behind it so not sure why this issue was reopened.
[~kramerul] Is this different from CALCITE-4188? If not then we should continue
the discussion there so other people tracking it can participate as well.
FYI: I had a first look at PR#3562 but didn't fully got how things work. I am
missing the big picture so need to spend more time on it. Will try to go over
it again in the next days.
> Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
> ---
>
> Key: CALCITE-5409
> URL: https://issues.apache.org/jira/browse/CALCITE-5409
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.33.0
>
>
> Adding the following unit test to {{JdbcAdapterTest}} causes an
> {{NullPointerException}}
> {code:java}
> @Test void testBatchNestedLoopJoin() {
> CalciteAssert.that()
> .with(CalciteConnectionProperty.LEX, Lex.JAVA)
> .with(CalciteConnectionProperty.FORCE_DECORRELATE, false)
> .withSchema("s", new ReflectiveSchema(new HrSchema()))
> .withModel(FoodmartSchema.FOODMART_MODEL)
> .query("select e.name from emps e join foodmart.store x on e.deptno =
> x.store_id")
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_CORRELATE_RULE);
>
> planner.addRule(EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE);
> })
> .runs();
> }
> {code}
> {code}
> Error while executing SQL "select e.name from emps e join foodmart.store x on
> e.deptno = x.store_id": Unable to implement
> EnumerableCalc(expr#0..2=[{inputs}], name=[$t0]): rowcount = 375.0,
> cumulative cost = {1465.0 rows, 2968.0 cpu, 0.0 io}, id = 174
> EnumerableBatchNestedLoopJoin(condition=[=($1, $2)], joinType=[inner],
> variablesSet=[[$cor0, ... $cor99]], batchSize=[100]): rowcount = 375.0,
> cumulative cost = {1090.0 rows, 1468.0 cpu, 0.0 io}, id = 170
> EnumerableCalc(expr#0..4=[{inputs}], expr#5=[CAST($t1):INTEGER NOT NULL],
> name=[$t2], deptno0=[$t5]): rowcount = 100.0, cumulative cost = {200.0 rows,
> 901.0 cpu, 0.0 io}, id = 176
> EnumerableTableScan(table=[[s, emps]]): rowcount = 100.0, cumulative
> cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 52
> JdbcToEnumerableConverter: rowcount = 25.0, cumulative cost = {207.5
> rows, 283.5 cpu, 0.0 io}, id = 168
> JdbcFilter(condition=[OR(=($cor0.deptno0, $0), ...)]): rowcount = 25.0,
> cumulative cost = {205.0 rows, 281.0 cpu, 0.0 io}, id = 166
> JdbcProject(store_id=[$0]): rowcount = 100.0, cumulative cost =
> {180.0 rows, 181.0 cpu, 0.0 io}, id = 164
> JdbcTableScan(table=[[foodmart, store]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 3
> ...
> Suppressed: java.lang.NullPointerException: variable $cor0 is not found
> {code}
> See also https://issues.apache.org/jira/browse/CALCITE-5354
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
