[jira] [Commented] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
[ https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815509#comment-17815509 ] Tanner Clary commented on CALCITE-6252: --- Any chance we can change the issue description? "Seems to use" leaves ambiguity > BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates > - > > Key: CALCITE-6252 > URL: https://issues.apache.org/jira/browse/CALCITE-6252 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > > For the following query: > {code:sql} > SELECT format_date('%A %d %B %Y', '0001-02-28') > {code} > the BigQuery playground returns the following result: > {code} > Monday 01 January 1 > {code} > However, Calcite returns the following result: > {code} > Saturday 01 Jan 1 > {code} > There are actually two bugs here: > - the day of the week is wrong > - the month name is displayed incorrectly. The latter is because of the > Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
[ https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815487#comment-17815487 ] Caican Cai commented on CALCITE-6252: - I seem to have encountered this bug before. You may have noticed that I once wrote a format_date test, but there are some format_date format tests that I did not add because my local machine passed the compilation, but the calcite cli did not pass. > BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates > - > > Key: CALCITE-6252 > URL: https://issues.apache.org/jira/browse/CALCITE-6252 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > > For the following query: > {code:sql} > SELECT format_date('%A %d %B %Y', '0001-02-28') > {code} > the BigQuery playground returns the following result: > {code} > Monday 01 January 1 > {code} > However, Calcite returns the following result: > {code} > Saturday 01 Jan 1 > {code} > There are actually two bugs here: > - the day of the week is wrong > - the month name is displayed incorrectly. The latter is because of the > Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
[ https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815484#comment-17815484 ] Mihai Budiu commented on CALCITE-6252: -- {color:#3367d6}SELECT{color}{color:#3a474e} {color}{color:#3367d6}format_date{color}{color:#37474f}({color}{color:#0d904f}'%A'{color}{color:#3a474e},{color}{color:#0d904f}'1582-01-01'{color}{color:#37474f}){color}{color:#3a474e}, {color}{color:#3367d6}format_date{color}{color:#37474f}({color}{color:#0d904f}'%A'{color}{color:#3a474e},{color}{color:#0d904f}'1582-12-12'{color}{color:#37474f}){color}{color:#3a474e}, {color}{color:#3367d6}format_date{color}{color:#37474f}({color}{color:#0d904f}'%A'{color}{color:#3a474e},{color}{color:#0d904f}'1752-01-01'{color}{color:#37474f}){color}{color:#3a474e}, {color}{color:#3367d6}format_date{color}{color:#37474f}({color}{color:#0d904f}'%A'{color}{color:#3a474e},{color}{color:#0d904f}'1752-12-12'{color}{color:#37474f}){color}{color:#3a474e}, {color}{color:#3367d6}format_date{color}{color:#37474f}({color}{color:#0d904f}'%A'{color}{color:#3a474e}, {color}{color:#0d904f}'2024-02-07'{color}{color:#37474f}){color} {color:#37474f}{color:#37474f}BigQuery:Friday, Sunday, Saturday, Tuesday, Wednesday {color}{color} {color:#37474f}{color:#37474f}Calcite: Monday, Sunday, Saturday, Tuesday, Wednesday{color}{color} {color:#37474f}{color:#37474f}So it seems to be in 1582.{color}{color} > BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates > - > > Key: CALCITE-6252 > URL: https://issues.apache.org/jira/browse/CALCITE-6252 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > > For the following query: > {code:sql} > SELECT format_date('%A %d %B %Y', '0001-02-28') > {code} > the BigQuery playground returns the following result: > {code} > Monday 01 January 1 > {code} > However, Calcite returns the following result: > {code} > Saturday 01 Jan 1 > {code} > There are actually two bugs here: > - the day of the week is wrong > - the month name is displayed incorrectly. The latter is because of the > Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
[ https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815481#comment-17815481 ] Mihai Budiu commented on CALCITE-6252: -- I suspect that's the case. The BigQuery documentation says that all dates are Gregorian: [https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types#date_type] ??The date type represents a Gregorian calendar date, independent of time zone.?? > BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates > - > > Key: CALCITE-6252 > URL: https://issues.apache.org/jira/browse/CALCITE-6252 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > > For the following query: > {code:sql} > SELECT format_date('%A %d %B %Y', '0001-02-28') > {code} > the BigQuery playground returns the following result: > {code} > Monday 01 January 1 > {code} > However, Calcite returns the following result: > {code} > Saturday 01 Jan 1 > {code} > There are actually two bugs here: > - the day of the week is wrong > - the month name is displayed incorrectly. The latter is because of the > Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
[ https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815479#comment-17815479 ] Julian Hyde edited comment on CALCITE-6252 at 2/8/24 2:30 AM: -- Do you know what date BigQuery diverges from Calcite? Is it perchance in October, 1582 or in September, 1752 (the Gregorian shift)? was (Author: julianhyde): Do you know what date BigQuery diverges from Calcite? Is it perchance in October, 1582 (the Gregorian shift)? > BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates > - > > Key: CALCITE-6252 > URL: https://issues.apache.org/jira/browse/CALCITE-6252 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > > For the following query: > {code:sql} > SELECT format_date('%A %d %B %Y', '0001-02-28') > {code} > the BigQuery playground returns the following result: > {code} > Monday 01 January 1 > {code} > However, Calcite returns the following result: > {code} > Saturday 01 Jan 1 > {code} > There are actually two bugs here: > - the day of the week is wrong > - the month name is displayed incorrectly. The latter is because of the > Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
[ https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815479#comment-17815479 ] Julian Hyde commented on CALCITE-6252: -- Do you know what date BigQuery diverges from Calcite? Is it perchance in October, 1582 (the Gregorian shift)? > BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates > - > > Key: CALCITE-6252 > URL: https://issues.apache.org/jira/browse/CALCITE-6252 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > > For the following query: > {code:sql} > SELECT format_date('%A %d %B %Y', '0001-02-28') > {code} > the BigQuery playground returns the following result: > {code} > Monday 01 January 1 > {code} > However, Calcite returns the following result: > {code} > Saturday 01 Jan 1 > {code} > There are actually two bugs here: > - the day of the week is wrong > - the month name is displayed incorrectly. The latter is because of the > Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6253) BigQuery FORMAT_DATE function does not implement all format specifiers
Mihai Budiu created CALCITE-6253: Summary: BigQuery FORMAT_DATE function does not implement all format specifiers Key: CALCITE-6253 URL: https://issues.apache.org/jira/browse/CALCITE-6253 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.36.0 Reporter: Mihai Budiu The following query: {code:sql} SELECT format_date('%A,%a,%B,%b,%C,%D,%d,%e,%F,%G,%g,%h,%j,%m,%U,%u,%V,%W,%w,%x,%Y,%y,%t,%%','2024-02-07') {code} produces the following output in Calcite: {code} Wednesday,Wed,Feb,Feb,%C,%D,07,07,2024-02-07,%G,%g,%h,038,02,%U,4,06,06,%w,02/07/24,2024,24,%t,%% {code} The expected output, checked in the BigQuery playground, is: {code} Wednesday,Wed,February,Feb,20,02/07/24,07, 7,2024-02-07,2024,24,Feb,038,02,05,3,06,06,3,02/07/24,2024,24,\t,% {code} This implies that the following format specifiers are not implemented: %C, %D, %G, %g, %h, %U, %w, %t, %%. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6252) BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates
Mihai Budiu created CALCITE-6252: Summary: BigQuery FORMAT_DATE seems to use the wrong calendar for Julian dates Key: CALCITE-6252 URL: https://issues.apache.org/jira/browse/CALCITE-6252 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.36.0 Reporter: Mihai Budiu For the following query: {code:sql} SELECT format_date('%A %d %B %Y', '0001-02-28') {code} the BigQuery playground returns the following result: {code} Monday 01 January 1 {code} However, Calcite returns the following result: {code} Saturday 01 Jan 1 {code} There are actually two bugs here: - the day of the week is wrong - the month name is displayed incorrectly. The latter is because of the Locale.ROOT used in SimpleDateFormat. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6228) ELEMENT function infers incorrect return type
[ https://issues.apache.org/jira/browse/CALCITE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Budiu resolved CALCITE-6228. -- Fix Version/s: 1.37.0 Resolution: Fixed Resolved in https://github.com/apache/calcite/commit/f837ffa877c5b7f795fd175532f6ec9db4440533 > ELEMENT function infers incorrect return type > - > > Key: CALCITE-6228 > URL: https://issues.apache.org/jira/browse/CALCITE-6228 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > The ELEMENT function is defined in the documentation as follows: > [https://calcite.apache.org/docs/reference.html#collection-functions] > {quote}Returns the sole element of an array or multiset; null if the > collection is empty; throws if it has more than one element. > {quote} > However, the type inference returns just the type of the element of the > collection, without changing its nullability. > The type inference is implemented as follows in SqlStdOperatorTable: > {code:java} > public static final SqlFunction ELEMENT = > SqlBasicFunction.create("ELEMENT", > ReturnTypes.MULTISET_ELEMENT_NULLABLE, > OperandTypes.COLLECTION); > {code} > However, reading the definition of MULTISET_ELEMENT_NULLABLE in > ReturnTypes.java: > {code:java} > public static final SqlReturnTypeInference MULTISET_ELEMENT_NULLABLE = > MULTISET.andThen(SqlTypeTransforms.TO_COLLECTION_ELEMENT_TYPE); > {code} > we notice that it is not forced to be nullable. Probably the correct > implementation would be > {code:java} > public static final SqlReturnTypeInference MULTISET_ELEMENT_NULLABLE = > MULTISET.andThen(SqlTypeTransforms.TO_COLLECTION_ELEMENT_TYPE) > .andThen(SqlTypeTransforms.FORCE_NULLABLE); > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6238) Exception while evaluating ROUND/TRUNCATE functions
[ https://issues.apache.org/jira/browse/CALCITE-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Budiu updated CALCITE-6238: - Summary: Exception while evaluating ROUND/TRUNCATE functions (was: Exception while evaluating ROUND function) > Exception while evaluating ROUND/TRUNCATE functions > --- > > Key: CALCITE-6238 > URL: https://issues.apache.org/jira/browse/CALCITE-6238 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > The following test in CalciteSqlOperatorTest: > {code:java} > @Test void testRoundFunc() { > final SqlOperatorFixture f = fixture(); > f.checkScalar("round(42, CAST(2 as BIGINT))", 42, "INTEGER NOT NULL"); > } > {code} > causes an exception; here is the relevant part of the stack trace: > {code} > java.sql.SQLException: Error while executing SQL "values (round(42, CAST(2 as > BIGINT)))": Unable to implement EnumerableCalc(expr#0=[{inputs}], > expr#1=[42], expr#2=[2:BIGINT], expr#3=[ROUND($t1, $t2)], EXPR$0=[$t3]): > rowcount = 1.0, cumulative cost = {2.0 rows, 6.0 cpu, 0.0 io}, id = 20 > EnumerableValues(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = {1.0 > rows, 1.0 cpu, 0.0 io}, id = 13 > ... > Suppressed: java.lang.RuntimeException: while resolving method > 'sround[int, long]' in class class org.apache.calcite.runtime.SqlFunctions > at > org.apache.calcite.adapter.enumerable.EnumUtils.call(EnumUtils.java:679) > at > org.apache.calcite.adapter.enumerable.RexImpTable$MethodImplementor.call(RexImpTable.java:2818) > at > org.apache.calcite.adapter.enumerable.RexImpTable$MethodImplementor.implementSafe(RexImpTable.java:2799) > at > org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3857) > at > org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3819) > {code} > And indeed, SqlFunctions does not have a function sround with this signature. > There are several possible fixes: > - reject calls to ROUND that have a BIGINT second argument > - have the validator insert an implicit cast for the second argument to > INTEGER > - implement more Java versions of the SROUND function in SqlFunctions. > Probably many more. > Which one of these is the right one? I suspect this problem applies to other > SQL functions as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6250) Improve MongoDB Documentation
[ https://issues.apache.org/jira/browse/CALCITE-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815308#comment-17815308 ] Corvin Kuebler commented on CALCITE-6250: - Hey all, please review the attached PR. After testing out the MongoDB adapter I quickly realized that its quite limited in capabilities. Please add this to the documentation. BR, Corvin > Improve MongoDB Documentation > - > > Key: CALCITE-6250 > URL: https://issues.apache.org/jira/browse/CALCITE-6250 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.35.0, 1.36.0 >Reporter: Corvin Kuebler >Assignee: Corvin Kuebler >Priority: Trivial > Labels: pull-request-available > > Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (CALCITE-6250) Improve MongoDB Documentation
[ https://issues.apache.org/jira/browse/CALCITE-6250 ] Corvin Kuebler deleted comment on CALCITE-6250: - was (Author: JIRAUSER299611): I have a PR for this ready in our fork of the project however im unable to create a PR back to the base repo since I get the error: Missing contributor rights. Can someone please help? BR, Corvin > Improve MongoDB Documentation > - > > Key: CALCITE-6250 > URL: https://issues.apache.org/jira/browse/CALCITE-6250 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.35.0, 1.36.0 >Reporter: Corvin Kuebler >Assignee: Corvin Kuebler >Priority: Trivial > Labels: pull-request-available > > Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6250) Improve MongoDB Documentation
[ https://issues.apache.org/jira/browse/CALCITE-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6250: Labels: pull-request-available (was: ) > Improve MongoDB Documentation > - > > Key: CALCITE-6250 > URL: https://issues.apache.org/jira/browse/CALCITE-6250 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.35.0, 1.36.0 >Reporter: Corvin Kuebler >Assignee: Corvin Kuebler >Priority: Trivial > Labels: pull-request-available > > Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6251) innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed
[ https://issues.apache.org/jira/browse/CALCITE-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815301#comment-17815301 ] Ulrich Kramer commented on CALCITE-6251: It's already there. > innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed > --- > > Key: CALCITE-6251 > URL: https://issues.apache.org/jira/browse/CALCITE-6251 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.36.0 >Reporter: Ulrich Kramer >Priority: Major > Labels: pull-request-available > > The > [innerEnumerator|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1681] > is only closed at the end. But if there are multiple loops, [innerEnumerator > is just assigned to a different value without closing > it|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1720]. > It should look like > [here|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1547-L1550]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6251) innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed
[ https://issues.apache.org/jira/browse/CALCITE-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6251: Labels: pull-request-available (was: ) > innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed > --- > > Key: CALCITE-6251 > URL: https://issues.apache.org/jira/browse/CALCITE-6251 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.36.0 >Reporter: Ulrich Kramer >Priority: Major > Labels: pull-request-available > > The > [innerEnumerator|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1681] > is only closed at the end. But if there are multiple loops, [innerEnumerator > is just assigned to a different value without closing > it|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1720]. > It should look like > [here|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1547-L1550]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6251) innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed
[ https://issues.apache.org/jira/browse/CALCITE-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815294#comment-17815294 ] Ruben Q L commented on CALCITE-6251: Well spotted [~kramerul]! Would you open a PR to fix this? > innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed > --- > > Key: CALCITE-6251 > URL: https://issues.apache.org/jira/browse/CALCITE-6251 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.36.0 >Reporter: Ulrich Kramer >Priority: Major > > The > [innerEnumerator|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1681] > is only closed at the end. But if there are multiple loops, [innerEnumerator > is just assigned to a different value without closing > it|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1720]. > It should look like > [here|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1547-L1550]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6251) innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed
Ulrich Kramer created CALCITE-6251: -- Summary: innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed Key: CALCITE-6251 URL: https://issues.apache.org/jira/browse/CALCITE-6251 Project: Calcite Issue Type: Bug Affects Versions: 1.36.0 Reporter: Ulrich Kramer The [innerEnumerator|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1681] is only closed at the end. But if there are multiple loops, [innerEnumerator is just assigned to a different value without closing it|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1720]. It should look like [here|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1547-L1550]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6249) RelNode::estimatedRowCount should not be used in computeSelfCost
[ https://issues.apache.org/jira/browse/CALCITE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6249: Labels: pull-request-available (was: ) > RelNode::estimatedRowCount should not be used in computeSelfCost > > > Key: CALCITE-6249 > URL: https://issues.apache.org/jira/browse/CALCITE-6249 > Project: Calcite > Issue Type: Bug >Reporter: Ulrich Kramer >Priority: Minor > Labels: pull-request-available > > {{RelNode::estimatedRowCount}} is still used in many place inside > {{computeSelfCost}} > If it should be possible to implement the estimation of the row count > completely outside Calcite, these calls should be replaced by > {{mq.getRowCount(rel)}}. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6249) RelNode::estimatedRowCount should not be used in computeSelfCost
[ https://issues.apache.org/jira/browse/CALCITE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815163#comment-17815163 ] Ulrich Kramer commented on CALCITE-6249: Yes, I will create a PR for this issue. > RelNode::estimatedRowCount should not be used in computeSelfCost > > > Key: CALCITE-6249 > URL: https://issues.apache.org/jira/browse/CALCITE-6249 > Project: Calcite > Issue Type: Bug >Reporter: Ulrich Kramer >Priority: Minor > > {{RelNode::estimatedRowCount}} is still used in many place inside > {{computeSelfCost}} > If it should be possible to implement the estimation of the row count > completely outside Calcite, these calls should be replaced by > {{mq.getRowCount(rel)}}. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5647) RelMdPopulationSize should use mq.getRowCount(rel) instead of rel.estimateRowCount(mq)
[ https://issues.apache.org/jira/browse/CALCITE-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815157#comment-17815157 ] Ruben Q L edited comment on CALCITE-5647 at 2/7/24 8:33 AM: Done in [{{f7069cc}}|https://github.com/apache/calcite/commit/f7069cc5245c22f816c565669f52b4f30b046f4d] Thanks [~adamkennedy77] and [~jduong] for working on this! was (Author: rubenql): Done in [{{f7069cc}}|https://github.com/apache/calcite/commit/f7069cc5245c22f816c565669f52b4f30b046f4d] > RelMdPopulationSize should use mq.getRowCount(rel) instead of > rel.estimateRowCount(mq) > -- > > Key: CALCITE-5647 > URL: https://issues.apache.org/jira/browse/CALCITE-5647 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Adam Kennedy >Assignee: Adam Kennedy >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > A few locations in Calcite call rel.estimateRowCount(mq) when they should > instead call mq.getRowCount(red). > We detected this because we implemented row count estimation entirely within > an alternative handle instead of RelMdRowCount, and then override > estimateRowCount to ensure the custom handler is user, by throwing an > unreachable code exception. > A few places in Calcite trigger these unreachable exceptions because they do > not use mq.getRowCount. > The most easily triggered on is in RelMdPopulationSize for the Values > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5647) RelMdPopulationSize should use mq.getRowCount(rel) instead of rel.estimateRowCount(mq)
[ https://issues.apache.org/jira/browse/CALCITE-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L updated CALCITE-5647: --- Fix Version/s: 1.37.0 > RelMdPopulationSize should use mq.getRowCount(rel) instead of > rel.estimateRowCount(mq) > -- > > Key: CALCITE-5647 > URL: https://issues.apache.org/jira/browse/CALCITE-5647 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Adam Kennedy >Assignee: Adam Kennedy >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > A few locations in Calcite call rel.estimateRowCount(mq) when they should > instead call mq.getRowCount(red). > We detected this because we implemented row count estimation entirely within > an alternative handle instead of RelMdRowCount, and then override > estimateRowCount to ensure the custom handler is user, by throwing an > unreachable code exception. > A few places in Calcite trigger these unreachable exceptions because they do > not use mq.getRowCount. > The most easily triggered on is in RelMdPopulationSize for the Values > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6250) Improve MongoDB Documentation
[ https://issues.apache.org/jira/browse/CALCITE-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815156#comment-17815156 ] Corvin Kuebler edited comment on CALCITE-6250 at 2/7/24 8:33 AM: - I have a PR for this ready in our fork of the project however im unable to create a PR back to the base repo since I get the error: Missing contributor rights. Can someone please help? BR, Corvin was (Author: JIRAUSER299611): I have a PR for this ready in our fork of the project however im unable to create a PR back to the base repo since I get the error: Missing contributor rights. Can someone help? > Improve MongoDB Documentation > - > > Key: CALCITE-6250 > URL: https://issues.apache.org/jira/browse/CALCITE-6250 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.35.0, 1.36.0 >Reporter: Corvin Kuebler >Assignee: Corvin Kuebler >Priority: Trivial > > Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6250) Improve MongoDB Documentation
[ https://issues.apache.org/jira/browse/CALCITE-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815156#comment-17815156 ] Corvin Kuebler commented on CALCITE-6250: - I have a PR for this ready in our fork of the project however im unable to create a PR back to the base repo since I get the error: Missing contributor rights. Can someone help? > Improve MongoDB Documentation > - > > Key: CALCITE-6250 > URL: https://issues.apache.org/jira/browse/CALCITE-6250 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.35.0, 1.36.0 >Reporter: Corvin Kuebler >Assignee: Corvin Kuebler >Priority: Trivial > > Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5647) RelMdPopulationSize should use mq.getRowCount(rel) instead of rel.estimateRowCount(mq)
[ https://issues.apache.org/jira/browse/CALCITE-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L resolved CALCITE-5647. Resolution: Fixed Done in [{{f7069cc}}|https://github.com/apache/calcite/commit/f7069cc5245c22f816c565669f52b4f30b046f4d] > RelMdPopulationSize should use mq.getRowCount(rel) instead of > rel.estimateRowCount(mq) > -- > > Key: CALCITE-5647 > URL: https://issues.apache.org/jira/browse/CALCITE-5647 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Adam Kennedy >Assignee: Adam Kennedy >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > A few locations in Calcite call rel.estimateRowCount(mq) when they should > instead call mq.getRowCount(red). > We detected this because we implemented row count estimation entirely within > an alternative handle instead of RelMdRowCount, and then override > estimateRowCount to ensure the custom handler is user, by throwing an > unreachable code exception. > A few places in Calcite trigger these unreachable exceptions because they do > not use mq.getRowCount. > The most easily triggered on is in RelMdPopulationSize for the Values > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6249) RelNode::estimatedRowCount should not be used in computeSelfCost
[ https://issues.apache.org/jira/browse/CALCITE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815152#comment-17815152 ] Ruben Q L commented on CALCITE-6249: [~kramerul] I think the current ticket is related to CALCITE-5647, but not a duplicate of it (I have updated the link between both accordingly). I think the commit that you propose seems reasonable, could you create the corresponding PR? > RelNode::estimatedRowCount should not be used in computeSelfCost > > > Key: CALCITE-6249 > URL: https://issues.apache.org/jira/browse/CALCITE-6249 > Project: Calcite > Issue Type: Bug >Reporter: Ulrich Kramer >Priority: Minor > > {{RelNode::estimatedRowCount}} is still used in many place inside > {{computeSelfCost}} > If it should be possible to implement the estimation of the row count > completely outside Calcite, these calls should be replaced by > {{mq.getRowCount(rel)}}. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6250) Improve MongoDB Documentation
Corvin Kuebler created CALCITE-6250: --- Summary: Improve MongoDB Documentation Key: CALCITE-6250 URL: https://issues.apache.org/jira/browse/CALCITE-6250 Project: Calcite Issue Type: Improvement Components: mongodb-adapter Affects Versions: 1.36.0, 1.35.0 Reporter: Corvin Kuebler Assignee: Corvin Kuebler Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)