[jira] [Commented] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762924#comment-17762924
]
Jiajun Xie commented on CALCITE-5944:
-
Fixed in
[64268b9|https://github.com/apache/calcite/commit/64268b9dd70bcdc15a3421ab120b8e5ecba17339].
Thanks for your review [~julianhyde] , [~rubenql], [~shenlang].{*}{*}
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5944.
-
Fix Version/s: 1.36.0
Resolution: Fixed
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5983) Add DIV and IEEE_DIVIDE functions (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762890#comment-17762890
]
Tanner Clary commented on CALCITE-5983:
---
[~julianhyde] This is a good point. I've written some basic tests included in a
past commit
[here|https://github.com/apache/calcite/blob/4e6c403842bebc519b1a1ededc9c2311059d7cb2/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L7156]
that convert those from strings, but not to them. I don't expect to encounter
any problems with that so I will include such tests in this case when I open
the PR.
For allowing them as literals, I think Postgres offers something like what's
seen in this question:
https://stackoverflow.com/questions/25927464/appropriate-values-for-infinity-infinity-in-postgres
> Add DIV and IEEE_DIVIDE functions (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5983
> URL: https://issues.apache.org/jira/browse/CALCITE-5983
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> BigQuery offers the DIV function
> ([docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#div])
> and the IEEE_DIVIDE function
> ([docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#ieee_divide]).
>
> The {{DIV(x, y)}} function returns the result of integer division of X by Y.
> Division by zero returns an error. Division by -1 may overflow.
> The {{IEEE_DIVIDE(x, y)}} function divides X by Y; this function never fails.
> Returns Double. Unlike the division operator (/), this function does not
> generate errors for division by zero or overflow.
> {{DIV}} examples:
> 1. {{DIV(20, 4)}} should return {{5}}.
> 2. {{DIV(2.5, 1)}} should return {{2}} because the result is floored to the
> nearest integer.
> 3. {{DIV(20, 0)}} should throw an error like: {{Division by zero}}.
> {{IEEE_DIVIDE}} examples:
> 1. {{DIV(20, 4)}} should return {{5.0}}.
> 2. {{DIV(20, 0)}} should return {{Infinity}}.
> 3. {{DIV(0, 0)}} should return {{NaN}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5982) Allow overloading the created enumerable in Calcite when calling getTables() or getColumns()
[
https://issues.apache.org/jira/browse/CALCITE-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee updated CALCITE-5982:
Description:
The goal is to introduce a mechanism that allows overloading the enumerable
type that is created when {{getTables()}} and {{getColumns()}} is called. If a
user provides an overloaded {{{}MetaTable{}}}/ {{MetaColumn}} class, then they
can add in additional metadata fields that they would like to be transferred.
Currently, {{CalciteMetaImpl}} in {{getTables()}} and {{getColumns()}} calls
are hardcoded to do reflection on {{MetaTable.class}} and {{MetaColumn.class}}
‘ fields, matched with the list of column names that are passed in. Reflection
is important here, as it creates the proper {{ColumnMetaData}} and
{{Signature}} that the client needs to deserialize.
See here for {{[getTables()|#L270]]}} and here for
[{{getColumns()}}|https://github.com/apache/calcite/blob/164ff0a27e243850d294908dc5cff90760d0a35a/core/src/main/java/org/apache/calcite/jdbc/CalciteMetaImpl.java#L320]
I would like to introduce fields ( {{metaTableClass}} , {{metaColumnClass}} )
on {{CalciteMetaImpl}} that determine which class to use for each of these.
This will be configured as a {{CalciteConnectionProperty}} when making the
{{jdbc:calcite}} connection, and default to MetaTable.class and
MetaColumn.class if not provided.
Requirements:
* User can specify in {{Properties}} new {{CalciteConnectionProperty}} ’s to
specify which overloaded class of {{CalciteMetaTable}} and {{MetaColumn}} to use
* If not specified, it will default to {{CalciteMetaTable.class}} and
{{MetaColumn.class}}
The provided overloaded class will create a subclass of {{CalciteMetaTable}} /
{{MetaColumn}} that has the same shape constructor and also provide an override
for the function {{{}getColumnNames(){}}}.
was:
The goal is to introduce a mechanism that allows overloading the enumerable
type that is created when {{getTables()}} and {{getColumns()}} is called. If a
user provides an overloaded {{{}MetaTable{}}}/ {{MetaColumn}} class, then they
can add in additional metadata fields that they would like to be transferred.
Currently, {{CalciteMetaImpl}} in {{getTables()}} and {{getColumns()}} calls
are hardcoded to do reflection on {{MetaTable.class}} and {{MetaColumn.class}}
‘ fields, matched with the list of column names that are passed in. Reflection
is important here, as it creates the proper {{ColumnMetaData}} and
{{Signature}} that the client needs to deserialize.
See here for {{[getTables()|#L270]]}} and here for
[{{getColumns()}}|https://github.com/apache/calcite/blob/164ff0a27e243850d294908dc5cff90760d0a35a/core/src/main/java/org/apache/calcite/jdbc/CalciteMetaImpl.java#L320]
I would like to introduce fields ( {{metaTableClass}} , {{metaColumnClass}} )
on {{CalciteMetaImpl}} that determine which class to use for each of these.
This will be configured as a {{CalciteConnectionProperty}} when making the
{{jdbc:calcite}} connection
Requirements:
* User can specify in {{Properties}} new {{CalciteConnectionProperty}} ’s to
specify which overloaded class of {{CalciteMetaTable}} and {{MetaColumn}} to use
* If not specified, it will default to {{CalciteMetaTable.class}} and
{{MetaColumn.class}}
The provided overloaded class will create a subclass of {{CalciteMetaTable}} /
{{MetaColumn}} that has the same shape constructor and also provide an override
for the function {{{}getColumnNames(){}}}.
> Allow overloading the created enumerable in Calcite when calling getTables()
> or getColumns()
> -
>
> Key: CALCITE-5982
> URL: https://issues.apache.org/jira/browse/CALCITE-5982
> Project: Calcite
> Issue Type: New Feature
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Major
>
> The goal is to introduce a mechanism that allows overloading the enumerable
> type that is created when {{getTables()}} and {{getColumns()}} is called. If
> a user provides an overloaded {{{}MetaTable{}}}/ {{MetaColumn}} class, then
> they can add in additional metadata fields that they would like to be
> transferred.
>
> Currently, {{CalciteMetaImpl}} in {{getTables()}} and {{getColumns()}} calls
> are hardcoded to do reflection on {{MetaTable.class}} and
> {{MetaColumn.class}} ‘ fields, matched with the list of column names that are
> passed in. Reflection is important here, as it creates the proper
> {{ColumnMetaData}} and {{Signature}} that the client needs to deserialize.
> See here for {{[getTables()|#L270]]}} and here for
> [{{getColumns()}}|https://github.com/apache/calcite/blob/164ff0a27e243850d294908dc5cff90760d0a35a/core/src/main/java/org/apache/calcite/jdbc/CalciteMetaImpl.java#L320]
>
>
> I would
[jira] [Commented] (CALCITE-5981) TIMESTAMPDIFF function returns incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762888#comment-17762888
]
Mihai Budiu commented on CALCITE-5981:
--
I have submitted a fix: https://github.com/apache/calcite-avatica/pull/226
I could not find unit tests for subtractMonths, so I ported some from MySQL.
(The bug is not really about leap years, the bug can appear in other
circumstances.)
It doesn't seem like Jira picks up PRs in Avatica automatically.
> TIMESTAMPDIFF function returns incorrect result
>
>
> Key: CALCITE-5981
> URL: https://issues.apache.org/jira/browse/CALCITE-5981
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> The following test fails, when added to SqlOperatorTest:
> {code:java}
> f.checkScalar("timestampdiff(month, DATE '2004-02-29', DATE '2005-02-28')",
> "11", "INTEGER NOT NULL");
> {code}
> The result returned by the expression is 12. However, MySQL returns 11.
> The semantics of this function is not described clearly in the documentation,
> but according to several prior issues [1] [2] [3] the intended semantics
> should be the same as in MySQL.
> A corresponding MySQL test: [4]
> The implementation seems to be in
> StandardConvertletTable.TimestampDiffConvertlet.
> [1] https://issues.apache.org/jira/browse/CALCITE-1827,
> [2] https://issues.apache.org/jira/browse/CALCITE-3529,
> [3] https://issues.apache.org/jira/browse/CALCITE-1124.
> [4]
> [https://github.com/mysql/mysql-server/blob/ea1efa9822d81044b726aab20c857d5e1b7e046a/mysql-test/r/func_time.result#L1151]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5983) Add DIV and IEEE_DIVIDE functions (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762886#comment-17762886
]
Julian Hyde commented on CALCITE-5983:
--
I don’t know whether IEEE values Infinity, NaN, etc. are valid values of the
DOUBLE SQL data type. Can you make sure that there are tests for basic
operations on them - converting them to strings, from strings, to integers, etc.
Do any dialects of SQL allow them as literals? E.g. {{DOUBLE ‘infinity’}} is
the kind of thing that Postgres might support.
If this stuff is non-trivial, feel free to cleave off a new jira case. Or maybe
it’s already done and I’ve missed it.
> Add DIV and IEEE_DIVIDE functions (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5983
> URL: https://issues.apache.org/jira/browse/CALCITE-5983
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> BigQuery offers the DIV function
> ([docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#div])
> and the IEEE_DIVIDE function
> ([docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#ieee_divide]).
>
> The {{DIV(x, y)}} function returns the result of integer division of X by Y.
> Division by zero returns an error. Division by -1 may overflow.
> The {{IEEE_DIVIDE(x, y)}} function divides X by Y; this function never fails.
> Returns Double. Unlike the division operator (/), this function does not
> generate errors for division by zero or overflow.
> {{DIV}} examples:
> 1. {{DIV(20, 4)}} should return {{5}}.
> 2. {{DIV(2.5, 1)}} should return {{2}} because the result is floored to the
> nearest integer.
> 3. {{DIV(20, 0)}} should throw an error like: {{Division by zero}}.
> {{IEEE_DIVIDE}} examples:
> 1. {{DIV(20, 4)}} should return {{5.0}}.
> 2. {{DIV(20, 0)}} should return {{Infinity}}.
> 3. {{DIV(0, 0)}} should return {{NaN}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5983) Add DIV and IEEE_DIVIDE functions (enabled in BigQuery library)
Tanner Clary created CALCITE-5983:
-
Summary: Add DIV and IEEE_DIVIDE functions (enabled in BigQuery
library)
Key: CALCITE-5983
URL: https://issues.apache.org/jira/browse/CALCITE-5983
Project: Calcite
Issue Type: Improvement
Reporter: Tanner Clary
Assignee: Tanner Clary
BigQuery offers the DIV function
([docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#div])
and the IEEE_DIVIDE function
([docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#ieee_divide]).
The {{DIV(x, y)}} function returns the result of integer division of X by Y.
Division by zero returns an error. Division by -1 may overflow.
The {{IEEE_DIVIDE(x, y)}} function divides X by Y; this function never fails.
Returns Double. Unlike the division operator (/), this function does not
generate errors for division by zero or overflow.
{{DIV}} examples:
1. {{DIV(20, 4)}} should return {{5}}.
2. {{DIV(2.5, 1)}} should return {{2}} because the result is floored to the
nearest integer.
3. {{DIV(20, 0)}} should throw an error like: {{Division by zero}}.
{{IEEE_DIVIDE}} examples:
1. {{DIV(20, 4)}} should return {{5.0}}.
2. {{DIV(20, 0)}} should return {{Infinity}}.
3. {{DIV(0, 0)}} should return {{NaN}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5935) Add CODE_POINTS_TO_BYTES function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762874#comment-17762874
]
Tanner Clary commented on CALCITE-5935:
---
[~hongyuguo] If you open pull requests for the other {{CODE_POINTS}} functions
please tag me I would be happy to help review.
> Add CODE_POINTS_TO_BYTES function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5935
> URL: https://issues.apache.org/jira/browse/CALCITE-5935
> Project: Calcite
> Issue Type: New Feature
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> CODE_POINTS_TO_BYTES(ascii_code_points): Takes an array of extended ASCII
> code points as {{ARRAY}} and returns {{BYTES}}
> see more in [BigQuery
> Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#code_points_to_bytes]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5935) Add CODE_POINTS_TO_BYTES function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-5935.
---
Resolution: Fixed
Merged via
[4e6c403|https://github.com/apache/calcite/commit/4e6c403842bebc519b1a1ededc9c2311059d7cb2],
thanks for the fix, [~hongyuguo], and the review, [~Runking]!
> Add CODE_POINTS_TO_BYTES function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5935
> URL: https://issues.apache.org/jira/browse/CALCITE-5935
> Project: Calcite
> Issue Type: New Feature
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> CODE_POINTS_TO_BYTES(ascii_code_points): Takes an array of extended ASCII
> code points as {{ARRAY}} and returns {{BYTES}}
> see more in [BigQuery
> Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#code_points_to_bytes]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5981) TIMESTAMPDIFF function returns incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762847#comment-17762847
]
Mihai Budiu commented on CALCITE-5981:
--
The TimestampDiffConvertlet seems correct, it converts the call of
timestampdiff(unit, end, start) to CAST(Reinterpret(Minus(end, start, month))):
The actual bug is in Avatica, in DateTimeUtils.subtractMonths, which doesn't
handle correctly the leap years.
subtractMonths(date0, date1) tries to find a number of months m such that
date1 + m - 1 <= date0 and date1 + m > date0
In our case date0 = "2005-02-28" and date1 = "2004-02-29".
date1 + 11 = "2005-01-29"
date1 + 12 = "2005-02-28" (because 2005-02-29 does not exist).
The correct m is 11, but this code chooses 12.
I think this code could be much simpler and does not need to iterate or guess m.
I will try to find the Avatica repository and submit a fix there.
> TIMESTAMPDIFF function returns incorrect result
>
>
> Key: CALCITE-5981
> URL: https://issues.apache.org/jira/browse/CALCITE-5981
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> The following test fails, when added to SqlOperatorTest:
> {code:java}
> f.checkScalar("timestampdiff(month, DATE '2004-02-29', DATE '2005-02-28')",
> "11", "INTEGER NOT NULL");
> {code}
> The result returned by the expression is 12. However, MySQL returns 11.
> The semantics of this function is not described clearly in the documentation,
> but according to several prior issues [1] [2] [3] the intended semantics
> should be the same as in MySQL.
> A corresponding MySQL test: [4]
> The implementation seems to be in
> StandardConvertletTable.TimestampDiffConvertlet.
> [1] https://issues.apache.org/jira/browse/CALCITE-1827,
> [2] https://issues.apache.org/jira/browse/CALCITE-3529,
> [3] https://issues.apache.org/jira/browse/CALCITE-1124.
> [4]
> [https://github.com/mysql/mysql-server/blob/ea1efa9822d81044b726aab20c857d5e1b7e046a/mysql-test/r/func_time.result#L1151]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5982) Allow overloading the created enumerable in Calcite when calling getTables() or getColumns()
Oliver Lee created CALCITE-5982:
---
Summary: Allow overloading the created enumerable in Calcite when
calling getTables() or getColumns()
Key: CALCITE-5982
URL: https://issues.apache.org/jira/browse/CALCITE-5982
Project: Calcite
Issue Type: New Feature
Reporter: Oliver Lee
Assignee: Oliver Lee
The goal is to introduce a mechanism that allows overloading the enumerable
type that is created when {{getTables()}} and {{getColumns()}} is called. If a
user provides an overloaded {{{}MetaTable{}}}/ {{MetaColumn}} class, then they
can add in additional metadata fields that they would like to be transferred.
Currently, {{CalciteMetaImpl}} in {{getTables()}} and {{getColumns()}} calls
are hardcoded to do reflection on {{MetaTable.class}} and {{MetaColumn.class}}
‘ fields, matched with the list of column names that are passed in. Reflection
is important here, as it creates the proper {{ColumnMetaData}} and
{{Signature}} that the client needs to deserialize.
See here for {{[getTables()|#L270]]}} and here for
[{{getColumns()}}|https://github.com/apache/calcite/blob/164ff0a27e243850d294908dc5cff90760d0a35a/core/src/main/java/org/apache/calcite/jdbc/CalciteMetaImpl.java#L320]
I would like to introduce fields ( {{metaTableClass}} , {{metaColumnClass}} )
on {{CalciteMetaImpl}} that determine which class to use for each of these.
This will be configured as a {{CalciteConnectionProperty}} when making the
{{jdbc:calcite}} connection
Requirements:
* User can specify in {{Properties}} new {{CalciteConnectionProperty}} ’s to
specify which overloaded class of {{CalciteMetaTable}} and {{MetaColumn}} to use
* If not specified, it will default to {{CalciteMetaTable.class}} and
{{MetaColumn.class}}
The provided overloaded class will create a subclass of {{CalciteMetaTable}} /
{{MetaColumn}} that has the same shape constructor and also provide an override
for the function {{{}getColumnNames(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5980) QuidemTests are not effectively executed on Windows
[
https://issues.apache.org/jira/browse/CALCITE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762840#comment-17762840
]
Ruben Q L commented on CALCITE-5980:
Sure. PR updated.
> QuidemTests are not effectively executed on Windows
> ---
>
> Key: CALCITE-5980
> URL: https://issues.apache.org/jira/browse/CALCITE-5980
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Discovered by accident on my Windows+IntelliJ environment while I was trying
> to add new tests on a *.iq file. My new tests did not seem to be executed. I
> even tried adding syntax errors on purpose into different iq files to force
> them to fail, but the tests were still successful. The reason seems to be
> that, at least on my environment (Windows), the test files do not execute any
> of their statements. This seems caused by the changes introduced in
> CALCITE-5786.
> While debugging, I found this line in QuidemTest.java (that aims to create
> the inFile and outFile):
> {code:java}
> protected void checkRun(String path) throws Exception {
> ...
> // e.g. path = "sql/agg.iq"
> // inUrl = "file:/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // inFile = "/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // outDir = "/home/fred/calcite/core/build/quidem/test/sql"
> // outFile = "/home/fred/calcite/core/build/quidem/test/sql/agg.iq"
> inFile = Sources.of(requireNonNull(inUrl, "inUrl")).file();
> outFile = replaceDir(inFile, "resources", "quidem");
> ...
> }
> {code}
> But in my case it results on {*}both files being the same{*}, thus when the
> outFile is created, it actually erases all the tests that were contained
> inside the inFile, so the test runs nothing.
> The reason for that is that the auxiliary method {{{}replaceDir{}}}:
> {code:java}
> private static File replaceDir(File file, String target, String
> replacement) {
> return new File(
> file.getAbsolutePath().replace(n2u('/' + target + '/'),
> n2u('/' + replacement + '/')));
> }
> {code}
> is trying to replace "/resources/" with "/quidem/" from the inFile absolute
> path, but in my case this path does not contain the pattern to be replaced,
> since it contains backslashes:
> "C:\...\calcite\core\build\resources\test\sql\agg.iq"; so the replacement
> operation does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5980) QuidemTests are not effectively executed on Windows
[
https://issues.apache.org/jira/browse/CALCITE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762824#comment-17762824
]
Julian Hyde commented on CALCITE-5980:
--
That makes sense. Can you add a comment that we disallow empty inFile because
it is a likely indication of overwrite? It's not technically wrong to have an
empty inFile (just as utilities such as {{cat}} and {{wc}} can work on empty
files).
> QuidemTests are not effectively executed on Windows
> ---
>
> Key: CALCITE-5980
> URL: https://issues.apache.org/jira/browse/CALCITE-5980
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Discovered by accident on my Windows+IntelliJ environment while I was trying
> to add new tests on a *.iq file. My new tests did not seem to be executed. I
> even tried adding syntax errors on purpose into different iq files to force
> them to fail, but the tests were still successful. The reason seems to be
> that, at least on my environment (Windows), the test files do not execute any
> of their statements. This seems caused by the changes introduced in
> CALCITE-5786.
> While debugging, I found this line in QuidemTest.java (that aims to create
> the inFile and outFile):
> {code:java}
> protected void checkRun(String path) throws Exception {
> ...
> // e.g. path = "sql/agg.iq"
> // inUrl = "file:/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // inFile = "/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // outDir = "/home/fred/calcite/core/build/quidem/test/sql"
> // outFile = "/home/fred/calcite/core/build/quidem/test/sql/agg.iq"
> inFile = Sources.of(requireNonNull(inUrl, "inUrl")).file();
> outFile = replaceDir(inFile, "resources", "quidem");
> ...
> }
> {code}
> But in my case it results on {*}both files being the same{*}, thus when the
> outFile is created, it actually erases all the tests that were contained
> inside the inFile, so the test runs nothing.
> The reason for that is that the auxiliary method {{{}replaceDir{}}}:
> {code:java}
> private static File replaceDir(File file, String target, String
> replacement) {
> return new File(
> file.getAbsolutePath().replace(n2u('/' + target + '/'),
> n2u('/' + replacement + '/')));
> }
> {code}
> is trying to replace "/resources/" with "/quidem/" from the inFile absolute
> path, but in my case this path does not contain the pattern to be replaced,
> since it contains backslashes:
> "C:\...\calcite\core\build\resources\test\sql\agg.iq"; so the replacement
> operation does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5860) Decimal type conversion missing scale
[
https://issues.apache.org/jira/browse/CALCITE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762821#comment-17762821
]
pengfei.zhan commented on CALCITE-5860:
---
[~zabetak] I found RelDataTypeImpl rewrite the method getScale() with
{code:java}
int SCALE_NOT_SPECIFIED = Integer.MIN_VALUE;{code}
Hmm, why it was set to the minimum value of Integer, I'm not really sure about
the exact reason behind it.
So, when using adjustDecimalScale in RexToLixTranslator, I add some more
restrictions to make sure that the targetType makes sense. Besides, a valid
RexLiteral need precision >= scale were added to this pr.
> Decimal type conversion missing scale
> -
>
> Key: CALCITE-5860
> URL: https://issues.apache.org/jira/browse/CALCITE-5860
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Guoliang Sun
>Assignee: pengfei.zhan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Take the following SQL as an example
> {code:sql}
> SELECT CAST(((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)) * SQRT(3.0) {code}
> The result of the SQL calculation should be {*}SQRT(3.0){*}.However, the
> actual result is {*}2.0{*}, which is not meet expectations.
>
> The following is the code generated by Janino
> {code:java}
> public Object[] apply(Object root0) {
> final java.math.BigDecimal literal_value = new java.math.BigDecimal(
> "2.0");
> final java.math.BigDecimal literal_value0 = new java.math.BigDecimal(
> "3.0");
> final java.math.BigDecimal literal_value1 = new java.math.BigDecimal(
> "0.5");
> final double method_name_call_value =
> org.apache.calcite.runtime.SqlFunctions.power(literal_value0, literal_value1);
> final java.math.BigDecimal cast_value = new java.math.BigDecimal(
> literal_value.doubleValue() / method_name_call_value);
> return new Object[] {
> cast_value == null ? 0.0D : cast_value.doubleValue() *
> method_name_call_value};
> } {code}
> We can see *((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)* lost the scale.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5971) Add the RelRule to rewrite the bernoulli sample as Filter
[
https://issues.apache.org/jira/browse/CALCITE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5971:
--
Fix Version/s: 1.36.0
> Add the RelRule to rewrite the bernoulli sample as Filter
> --
>
> Key: CALCITE-5971
> URL: https://issues.apache.org/jira/browse/CALCITE-5971
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Fix For: 1.36.0
>
>
> For the following SQL:
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50); {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand() < 0.5; {code}
> The sql :
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
> {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand(10) < 0.5; {code}
> This rule only rewrite the tablesample bernoulli.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5971) Add the RelRule to rewrite the bernoulli sample as Filter
[
https://issues.apache.org/jira/browse/CALCITE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762713#comment-17762713
]
LakeShen commented on CALCITE-5971:
---
This PR is Ready, PR link : https://github.com/apache/calcite/pull/3410
If others have time, please help me to review it, thank you very much:)
> Add the RelRule to rewrite the bernoulli sample as Filter
> --
>
> Key: CALCITE-5971
> URL: https://issues.apache.org/jira/browse/CALCITE-5971
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> For the following SQL:
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50); {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand() < 0.5; {code}
> The sql :
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
> {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand(10) < 0.5; {code}
> This rule only rewrite the tablesample bernoulli.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5971) Add the RelRule to rewrite the bernoulli sample as Filter
[
https://issues.apache.org/jira/browse/CALCITE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5971:
--
Summary: Add the RelRule to rewrite the bernoulli sample as Filter (was:
Add the RelRule to rewrite the Sample as Filter)
> Add the RelRule to rewrite the bernoulli sample as Filter
> --
>
> Key: CALCITE-5971
> URL: https://issues.apache.org/jira/browse/CALCITE-5971
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> For the following SQL:
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50); {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand() < 0.5; {code}
> The sql :
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
> {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand(10) < 0.5; {code}
> This rule only rewrite the tablesample bernoulli.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5980) QuidemTests are not effectively executed on Windows
[
https://issues.apache.org/jira/browse/CALCITE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762596#comment-17762596
]
Ruben Q L commented on CALCITE-5980:
What about checking that each inFile must not be empty? That check fails on
current master, but passes on my branch.
> QuidemTests are not effectively executed on Windows
> ---
>
> Key: CALCITE-5980
> URL: https://issues.apache.org/jira/browse/CALCITE-5980
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Discovered by accident on my Windows+IntelliJ environment while I was trying
> to add new tests on a *.iq file. My new tests did not seem to be executed. I
> even tried adding syntax errors on purpose into different iq files to force
> them to fail, but the tests were still successful. The reason seems to be
> that, at least on my environment (Windows), the test files do not execute any
> of their statements. This seems caused by the changes introduced in
> CALCITE-5786.
> While debugging, I found this line in QuidemTest.java (that aims to create
> the inFile and outFile):
> {code:java}
> protected void checkRun(String path) throws Exception {
> ...
> // e.g. path = "sql/agg.iq"
> // inUrl = "file:/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // inFile = "/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // outDir = "/home/fred/calcite/core/build/quidem/test/sql"
> // outFile = "/home/fred/calcite/core/build/quidem/test/sql/agg.iq"
> inFile = Sources.of(requireNonNull(inUrl, "inUrl")).file();
> outFile = replaceDir(inFile, "resources", "quidem");
> ...
> }
> {code}
> But in my case it results on {*}both files being the same{*}, thus when the
> outFile is created, it actually erases all the tests that were contained
> inside the inFile, so the test runs nothing.
> The reason for that is that the auxiliary method {{{}replaceDir{}}}:
> {code:java}
> private static File replaceDir(File file, String target, String
> replacement) {
> return new File(
> file.getAbsolutePath().replace(n2u('/' + target + '/'),
> n2u('/' + replacement + '/')));
> }
> {code}
> is trying to replace "/resources/" with "/quidem/" from the inFile absolute
> path, but in my case this path does not contain the pattern to be replaced,
> since it contains backslashes:
> "C:\...\calcite\core\build\resources\test\sql\agg.iq"; so the replacement
> operation does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5980) QuidemTests are not effectively executed on Windows
[
https://issues.apache.org/jira/browse/CALCITE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762596#comment-17762596
]
Ruben Q L edited comment on CALCITE-5980 at 9/7/23 7:28 AM:
What about checking that each inFile must not be empty? On my env, that check
fails on current master, but passes on my branch.
was (Author: rubenql):
What about checking that each inFile must not be empty? That check fails on
current master, but passes on my branch.
> QuidemTests are not effectively executed on Windows
> ---
>
> Key: CALCITE-5980
> URL: https://issues.apache.org/jira/browse/CALCITE-5980
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Discovered by accident on my Windows+IntelliJ environment while I was trying
> to add new tests on a *.iq file. My new tests did not seem to be executed. I
> even tried adding syntax errors on purpose into different iq files to force
> them to fail, but the tests were still successful. The reason seems to be
> that, at least on my environment (Windows), the test files do not execute any
> of their statements. This seems caused by the changes introduced in
> CALCITE-5786.
> While debugging, I found this line in QuidemTest.java (that aims to create
> the inFile and outFile):
> {code:java}
> protected void checkRun(String path) throws Exception {
> ...
> // e.g. path = "sql/agg.iq"
> // inUrl = "file:/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // inFile = "/home/fred/calcite/core/build/resources/test/sql/agg.iq"
> // outDir = "/home/fred/calcite/core/build/quidem/test/sql"
> // outFile = "/home/fred/calcite/core/build/quidem/test/sql/agg.iq"
> inFile = Sources.of(requireNonNull(inUrl, "inUrl")).file();
> outFile = replaceDir(inFile, "resources", "quidem");
> ...
> }
> {code}
> But in my case it results on {*}both files being the same{*}, thus when the
> outFile is created, it actually erases all the tests that were contained
> inside the inFile, so the test runs nothing.
> The reason for that is that the auxiliary method {{{}replaceDir{}}}:
> {code:java}
> private static File replaceDir(File file, String target, String
> replacement) {
> return new File(
> file.getAbsolutePath().replace(n2u('/' + target + '/'),
> n2u('/' + replacement + '/')));
> }
> {code}
> is trying to replace "/resources/" with "/quidem/" from the inFile absolute
> path, but in my case this path does not contain the pattern to be replaced,
> since it contains backslashes:
> "C:\...\calcite\core\build\resources\test\sql\agg.iq"; so the replacement
> operation does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762576#comment-17762576 ] Evgeny Stanilovsky commented on CALCITE-5957: - patch is reviewed, wait for merge. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
