[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)
