[jira] [Resolved] (CALCITE-5997) OFFSET operator is incorrectly unparsed
[
https://issues.apache.org/jira/browse/CALCITE-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5997.
-
Fix Version/s: 1.36.0
Assignee: Mihai Budiu
Resolution: Fixed
> OFFSET operator is incorrectly unparsed
> ---
>
> Key: CALCITE-5997
> URL: https://issues.apache.org/jira/browse/CALCITE-5997
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The following query:
> {code:sql}
> select ARRAY[p2,p1,p0][OFFSET(2)] from (values (6, 4, 2)) as t(p0, p1, p2)
> {code}
> when parsed as a SqlNode and then unparsed produces:
> {code:sql}
> SELECT ARRAY["P2", "P1", "P0"][2]
> FROM (VALUES ROW(6, 4, 2)) AS "T" ("P0", "P1", "P2")
> {code}
> which no longer produces the same result (the OFFSET function call is
> missing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5997) OFFSET operator is incorrectly unparsed
[
https://issues.apache.org/jira/browse/CALCITE-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766961#comment-17766961
]
Jiajun Xie commented on CALCITE-5997:
-
Fixed in
[9ce7077|https://github.com/apache/calcite/commit/9ce7077bc8353e21e71ddb9f4a6a3025422ea8c4].
Thanks for the PR [~mbudiu] .
Thanks for the review [~tanclary] .
> OFFSET operator is incorrectly unparsed
> ---
>
> Key: CALCITE-5997
> URL: https://issues.apache.org/jira/browse/CALCITE-5997
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following query:
> {code:sql}
> select ARRAY[p2,p1,p0][OFFSET(2)] from (values (6, 4, 2)) as t(p0, p1, p2)
> {code}
> when parsed as a SqlNode and then unparsed produces:
> {code:sql}
> SELECT ARRAY["P2", "P1", "P0"][2]
> FROM (VALUES ROW(6, 4, 2)) AS "T" ("P0", "P1", "P2")
> {code}
> which no longer produces the same result (the OFFSET function call is
> missing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5961) Type inference of ARRAY_COMPACT is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiong duan resolved CALCITE-5961.
-
Fix Version/s: 1.36.0
Resolution: Fixed
> Type inference of ARRAY_COMPACT is incorrect
>
>
> Key: CALCITE-5961
> URL: https://issues.apache.org/jira/browse/CALCITE-5961
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The return type of
> {code:java}
> array_compact(array[null, 1, null, 2]){code}
> is INTEGER ARRAY NOT NULL, but from semantics the correct type should be
> INTEGER NOT NULL ARRAY NOT NULL.
> because the returned result can not has NULL value.
> currently, array_compact use ARG0_NULLABLE which is not enough.
> {code:java}
> public static final SqlFunction ARRAY_COMPACT =
> SqlBasicFunction.create(SqlKind.ARRAY_COMPACT,
> ReturnTypes.ARG0_NULLABLE,
> OperandTypes.ARRAY);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5961) Type inference of ARRAY_COMPACT is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766947#comment-17766947
]
xiong duan commented on CALCITE-5961:
-
Fixed in
[abb3e5b|https://github.com/apache/calcite/commit/abb3e5be43c9d030bea6489cc8ee42a2905fc4e8].
Thanks for the PR [~taoran] .
> Type inference of ARRAY_COMPACT is incorrect
>
>
> Key: CALCITE-5961
> URL: https://issues.apache.org/jira/browse/CALCITE-5961
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
>
> The return type of
> {code:java}
> array_compact(array[null, 1, null, 2]){code}
> is INTEGER ARRAY NOT NULL, but from semantics the correct type should be
> INTEGER NOT NULL ARRAY NOT NULL.
> because the returned result can not has NULL value.
> currently, array_compact use ARG0_NULLABLE which is not enough.
> {code:java}
> public static final SqlFunction ARRAY_COMPACT =
> SqlBasicFunction.create(SqlKind.ARRAY_COMPACT,
> ReturnTypes.ARG0_NULLABLE,
> OperandTypes.ARRAY);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (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=17766814#comment-17766814 ] Runkang He edited comment on CALCITE-5957 at 9/19/23 2:24 PM: -- I agree Julian's explanation, and then I think CALCITE-5678 is not intended to fully use strict ISO-8601 standard to replace the old way. So now we still use the old date parsing method. The plan to use strict ISO-8601 standard may need more discussion later. As [~zabetak] pointed out, people have different opinions on the topic, and I also prefer to use strict mode personally. I think '900-01-01' is valid to keep consistent with other parts of date or time with leading zeros. '2023-01-01 22:00:00.123.123' is invalid because the last '.123' is invalid as a time string. We need correct punctuations to define the valid date and time string, and should reject the wrong punctuations. was (Author: JIRAUSER280488): I agree Julian's explanation, and then I think CALCITE-5678 is not intended to fully use strict ISO-8601 standard to replace the old way. So now we still use the old date parsing method. The plan to use strict ISO-8601 standard may need more discussion later. As [~zabetak] pointed out, people have different opinions on the topic, and I also pefer to use strict mode personally. I think '900-01-01' is valid to keep consistent with other parts of date or time with leading zeros. '2023-01-01 22:00:00.123.123' is invalid because the last '.123' is invalid as a time string. We need correct punctuations to define the valid date and time string, and should reject the wrong punctuations. > 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 >Priority: Blocker > 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)
[jira] [Comment Edited] (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=17766814#comment-17766814 ] Runkang He edited comment on CALCITE-5957 at 9/19/23 2:24 PM: -- I agree Julian's explanation, and then I think CALCITE-5678 is not intended to fully use strict ISO-8601 standard to replace the old way. So now we still use the old date parsing method. The plan to use strict ISO-8601 standard may need more discussion later. As [~zabetak] pointed out, people have different opinions on the topic, and I also prefer to use strict mode personally. I think '900-01-01' is valid, to keep consistent with other parts of date or time with leading zeros. '2023-01-01 22:00:00.123.123' is invalid because the last '.123' is invalid as a time string. We need correct punctuations to define the valid date and time string, and should reject the wrong punctuations. was (Author: JIRAUSER280488): I agree Julian's explanation, and then I think CALCITE-5678 is not intended to fully use strict ISO-8601 standard to replace the old way. So now we still use the old date parsing method. The plan to use strict ISO-8601 standard may need more discussion later. As [~zabetak] pointed out, people have different opinions on the topic, and I also prefer to use strict mode personally. I think '900-01-01' is valid to keep consistent with other parts of date or time with leading zeros. '2023-01-01 22:00:00.123.123' is invalid because the last '.123' is invalid as a time string. We need correct punctuations to define the valid date and time string, and should reject the wrong punctuations. > 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 >Priority: Blocker > 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)
[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=17766814#comment-17766814 ] Runkang He commented on CALCITE-5957: - I agree Julian's explanation, and then I think CALCITE-5678 is not intended to fully use strict ISO-8601 standard to replace the old way. So now we still use the old date parsing method. The plan to use strict ISO-8601 standard may need more discussion later. As [~zabetak] pointed out, people have different opinions on the topic, and I also pefer to use strict mode personally. I think '900-01-01' is valid to keep consistent with other parts of date or time with leading zeros. '2023-01-01 22:00:00.123.123' is invalid because the last '.123' is invalid as a time string. We need correct punctuations to define the valid date and time string, and should reject the wrong punctuations. > 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 >Priority: Blocker > 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)
[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=17766775#comment-17766775
]
Evgeny Stanilovsky commented on CALCITE-5957:
-
ok i check, all these cases : ("900-01-01" , "2023-01-01 22:00:00.123.123") are
passed with no exception through
{code:java}
DateTimeUtils.timestampStringToUnixDate
{code}
before CALCITE-5678:
> 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
>Priority: Blocker
> 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)
[jira] [Comment Edited] (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=17766765#comment-17766765 ] Evgeny Stanilovsky edited comment on CALCITE-5957 at 9/19/23 11:40 AM: --- "900-01-01" ok i take a look on it a bit later, also i close this PR, because in _sql 2016 standard_ section : "Valid values for datetime fields" i found no information about single digits. If someone wants to continue with that - feel free to take this issue. was (Author: zstan): "900-01-01" ok i take a look on it a bit later, also i close this PR, because in section : "Valid values for datetime fields" i found no information about single digits. If someone wants to continue with that - feel free to take this issue. > 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 >Priority: Blocker > 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)
[jira] [Comment Edited] (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=17766765#comment-17766765 ] Evgeny Stanilovsky edited comment on CALCITE-5957 at 9/19/23 11:39 AM: --- "900-01-01" ok i take a look on it a bit later, also i close this PR, because in section : "Valid values for datetime fields" i found no information about single digits. If someone wants to continue with that - feel free to take this issue. was (Author: zstan): "900-01-01" ok i take a look on it a bit later, also a close this PR, because in section : "Valid values for datetime fields" i found no information about single digits. If someone wants to continue with that - feel free to take this issue. > 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 >Priority: Blocker > 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)
[jira] [Assigned] (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:all-tabpanel ] Evgeny Stanilovsky reassigned CALCITE-5957: --- Assignee: (was: Evgeny Stanilovsky) > 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 >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)
[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=17766765#comment-17766765 ] Evgeny Stanilovsky commented on CALCITE-5957: - "900-01-01" ok i take a look on it a bit later, also a close this PR, because in section : "Valid values for datetime fields" i found no information about single digits. If someone wants to continue with that - feel free to take this issue. > 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)
[jira] [Updated] (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:all-tabpanel ] Evgeny Stanilovsky updated CALCITE-5957: Labels: (was: pull-request-available) > 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 >Priority: Blocker > 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)
[jira] [Updated] (CALCITE-5994) Add optimization rule to remove Sort when its input's row number is less or equal to one
[
https://issues.apache.org/jira/browse/CALCITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5994:
--
Summary: Add optimization rule to remove Sort when its input's row number
is less or equal to one (was: Add the optimize for removing the redundant
order by when its source row number is less than or equal 1)
> Add optimization rule to remove Sort when its input's row number is less or
> equal to one
>
>
> Key: CALCITE-5994
> URL: https://issues.apache.org/jira/browse/CALCITE-5994
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When a Sort's input source max row numer is 1,then we could remove the
> redundant Sort,the Sort could be a sorted semantic Sort(offset and fetch is
> null).
> For example,the sql:
> {code:java}
> select * from (select * from tableA limit 1) order by c ;
> {code}
> because the `(select * from tableA limit 1) ` max row number is 1, then we
> could remove order by c
> {code:java}
> select * from tableA limit 1;
> {code}
> The sql:
> {code:java}
> select max(totalprice) from orders order by 1 {code}
> could converted to:
> {code:java}
> select max(totalprice) from orders{code}
> Above logic are same as Presto/Trino's
> [RemoveRedundantSort|https://github.com/prestodb/presto/blob/c21fc28846252cd910d90f046514bf586d7bb5c6/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantSort.java#L27]
> rule:
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5927) LoptOptimizeJoinRule has wrong condition when finding out if Self-Join keys are unique
[
https://issues.apache.org/jira/browse/CALCITE-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766760#comment-17766760
]
qiang.wang commented on CALCITE-5927:
-
[~jhyde] hi, i have submit a PR to fix this issue, could you please help to
review this pr? thanks
> LoptOptimizeJoinRule has wrong condition when finding out if Self-Join keys
> are unique
> --
>
> Key: CALCITE-5927
> URL: https://issues.apache.org/jira/browse/CALCITE-5927
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.33.0, 1.34.0, 1.35.0
>Reporter: qiang.wang
>Assignee: qiang.wang
>Priority: Minor
> Labels: pull-request-available
>
> There's wrong condition in function _areSelfJoinKeysUnique._
>
> {code:java}
> // Make sure each key on the left maps to the same simple column as the
> // corresponding key on the right
> for (IntPair pair : joinInfo.pairs()) {
> final RelColumnOrigin leftOrigin =
> mq.getColumnOrigin(leftRel, pair.source);
> if (leftOrigin == null || !leftOrigin.isDerived()) {
> return false;
> }
> final RelColumnOrigin rightOrigin =
> mq.getColumnOrigin(rightRel, pair.target);
> if (rightOrigin == null || !rightOrigin.isDerived()) {
> return false;
> }
> if (leftOrigin.getOriginColumnOrdinal()
> != rightOrigin.getOriginColumnOrdinal()) {
> return false;
> }
> } {code}
> The wrong conditions are '{_}if (leftOrigin == null ||
> !leftOrigin.isDerived()){_}' and '{_}if (rightOrigin == null ||
> !rightOrigin.isDerived()){_}'.
> This function wants to find out if the self-join keys are unique. so for each
> self-join key, find
> _leftOrigin_ and _rightOrigin_ first, then will return false if any of them
> is null. But why it returns false when any of them is not _Derived?_ I think
> exactly the opposite is right.
> I think this is a bug comes from CALCITE-4251
> Before that PR, this function will return false only when _leftOrigin_ or
> _rightOrigin_ is null, and the function _RelMetadataQuery#getColumnOrigin_
> will return null if column is derived, so the logic is : 'this function will
> return null when _leftOrigin_ or _rightOrigin_ is null or is derived', but
> now is : 'this function will return null when _leftOrigin_ or _rightOrigin_
> is null or is not derived'.
>
--
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=17766725#comment-17766725 ] Stamatis Zampetakis commented on CALCITE-5957: -- The SQL standard 2011 Section 5.3 (Syntax Rules) defines the following: 31) Within a , the shall contain four digits. The and other datetime components, with the exception of , shall each contain two digits. 32) Within the definition of a , the s are constrained by the natural rules for dates and times according to the Gregorian calendar. However, we already started deviating from the strict standard definition so I am not sure why we should allow single digit integers for everything (months, days, hours, minutes, seconds) but not for years; this seems inconsistent. Personally, I prefer the strict format but this is completely subjective and people have different opinions on the topic so I am willing to follow the majority. Nevertheless, we should clarify if the date "900-01-01" was valid before the changes in CALCITE-5678 or not. [~zstan] Also please comment about "2023-01-01 22:00:00.123.123". Was it valid before CALCITE-5678? Should we accept it now? > 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)
[jira] [Comment Edited] (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=17766659#comment-17766659 ] Evgeny Stanilovsky edited comment on CALCITE-5957 at 9/19/23 6:42 AM: -- [~zabetak] as i can see from iso standard [1] : *ISO 8601 prescribes, as a minimum, a four-digit year [] to avoid the year 2000 problem.* So "0900-01-01" is correct while "900-01-01" is not. Also SQL standard (6.1 chapter, Valid values for datetime fields) determines: YEAR : 0001 to [1] https://en.wikipedia.org/wiki/ISO_8601 was (Author: zstan): [~zabetak] as i can see from iso standard [1] : *ISO 8601 prescribes, as a minimum, a four-digit year [] to avoid the year 2000 problem.* So "0900-01-01" is correct while "900-01-01" is not. [1] https://en.wikipedia.org/wiki/ISO_8601 > 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)
[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=17766659#comment-17766659 ] Evgeny Stanilovsky commented on CALCITE-5957: - [~zabetak] as i can see from iso standard [1] : *ISO 8601 prescribes, as a minimum, a four-digit year [] to avoid the year 2000 problem.* So "0900-01-01" is correct while "900-01-01" is not. [1] https://en.wikipedia.org/wiki/ISO_8601 > 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)
[jira] [Created] (CALCITE-6016) Cannot execute SQL on Snowflake connection with error : java.lang.IllegalArgumentException: Multiple entries with same key: CLASSES=JdbcTable {CLASSES} and CLASSES=Jdbc
Vishal Wakchaure created CALCITE-6016:
-
Summary: Cannot execute SQL on Snowflake connection with error :
java.lang.IllegalArgumentException: Multiple entries with same key:
CLASSES=JdbcTable {CLASSES} and CLASSES=JdbcTable {CLASSES}
Key: CALCITE-6016
URL: https://issues.apache.org/jira/browse/CALCITE-6016
Project: Calcite
Issue Type: Bug
Components: jdbc-adapter
Affects Versions: 1.35.0
Reporter: Vishal Wakchaure
_Can be similar to : https://issues.apache.org/jira/browse/DRILL-7415_
I am connected to Snowflake datasource using calcite connection and I am trying
to execute SQL using a statement.
I have only single table in database.
My code :
{code:java}
public static boolean getSnowflakeConnection() throws SQLException {
String modelPath = "/Users/A200118159/Documents/Code/TestSpringBoot
2/src/main/resources/models/snowflake_model.json";
//"/Users/A200118159/test/snowflake_model.json";
Properties properties = new Properties();
properties.setProperty("model", modelPath);
properties.setProperty("caseSensitive", "false");
// Create a Calcite connection
Connection connection = DriverManager.getConnection("jdbc:calcite:",
properties);
CalciteConnection calciteConnection =
connection.unwrap(CalciteConnection.class);
Statement statement = calciteConnection.createStatement();
ResultSet resultSet = statement.executeQuery("SELECT * FROM PRODUCTS");
printTable(resultSet);
calciteConnection.close();
return true;
} {code}
Snowflake Model File:
{code:java}
{
"version": "1.0",
"defaultSchema": "Snowflake",
"schemas": [
{
"name": "Snowflake",
"type": "custom",
"factory": "org.apache.calcite.adapter.jdbc.JdbcSchema$Factory",
"operand": {
"jdbcUser": "argus",
"jdbcPassword": "Argus123",
"jdbcUrl":
"jdbc:snowflake://er14275.ap-southeast-1.snowflakecomputing.com/?warehouse=COMPUTE_WH=ARGUS_DATA=ARGUS_SCHEMA",
"jdbcDriver": "net.snowflake.client.jdbc.SnowflakeDriver"
}
}
]
} {code}
But I am getting below error:
java.lang.IllegalArgumentException: Multiple entries with same key:
CLASSES=JdbcTable \{CLASSES} and CLASSES=JdbcTable \{CLASSES}
at
com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:136)
~[guava-19.0.jar:na]
at
com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:98)
~[guava-19.0.jar:na]
at
com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:84)
~[guava-19.0.jar:na]
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:295)
~[guava-19.0.jar:na]
at
org.apache.calcite.adapter.jdbc.JdbcSchema.computeTables(JdbcSchema.java:305)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.adapter.jdbc.JdbcSchema.getTableMap(JdbcSchema.java:361)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.adapter.jdbc.JdbcSchema.getTableNames(JdbcSchema.java:489)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.jdbc.CachingCalciteSchema$2.build(CachingCalciteSchema.java:86)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.jdbc.CachingCalciteSchema$2.build(CachingCalciteSchema.java:83)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.jdbc.CachingCalciteSchema$AbstractCached.get(CachingCalciteSchema.java:318)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.jdbc.CachingCalciteSchema.getImplicitTable(CachingCalciteSchema.java:142)
~[calcite-core-1.35.0.jar:1.35.0]
at org.apache.calcite.jdbc.CalciteSchema.getTable(CalciteSchema.java:295)
~[calcite-core-1.35.0.jar:1.35.0]
at org.apache.calcite.sql.validate.EmptyScope.resolve_(EmptyScope.java:144)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.EmptyScope.resolveTable(EmptyScope.java:101)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.DelegatingScope.resolveTable(DelegatingScope.java:230)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.IdentifierNamespace.resolveImpl(IdentifierNamespace.java:116)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.IdentifierNamespace.validateImpl(IdentifierNamespace.java:188)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1115)
~[calcite-core-1.35.0.jar:1.35.0]
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3456)
~[calcite-core-1.35.0.jar:1.35.0]
at
