[jira] [Assigned] (IGNITE-22788) Sql. Support of FORMAT clause of the CAST operator
[
https://issues.apache.org/jira/browse/IGNITE-22788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reassigned IGNITE-22788:
---
Assignee: Iurii Gerzhedovich
> Sql. Support of FORMAT clause of the CAST operator
> ---
>
> Key: IGNITE-22788
> URL: https://issues.apache.org/jira/browse/IGNITE-22788
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Calcite 1.37 brings -support of FORMAT clause of the CAST operator -,
> unfortunately, it doent's work automatically in AI3 and leads to assertion
> during planning phase. E.g. for query
> {code:java}
> select cast('18-12-03' as date format 'YY-MM-DD'){code}
> we got
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3213)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3811)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3763)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1269)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:113)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1145)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:274)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:268)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:985)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:222)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:103)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:70)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.reduce(RexExecutorImpl.java:157)
> at org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2274)
> at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
> at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
> at
> org.apache.calcite.tools.RelBuilder.lambda$project_$7(RelBuilder.java:2050)
> {code}
> Seems we need just synchronize all our code which was copy-pasted to us:
> RexToLixTranslator, RexImpTable, e.t.c
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22829) Sql. Optimize performance of count(*)
Iurii Gerzhedovich created IGNITE-22829: --- Summary: Sql. Optimize performance of count(*) Key: IGNITE-22829 URL: https://issues.apache.org/jira/browse/IGNITE-22829 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich We have an API to get the size of a table we can implement optimization to rapid return result of count(*) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18789) Sql. The sign of the default values for precision and scale is not kept
[
https://issues.apache.org/jira/browse/IGNITE-18789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-18789:
Description:
SQL standard (P 4.4.1) says:
{code:java}
If or is not specified explicitly, then the corresponding
element of the descriptor effectively contains the null value.{code}
But we keep our default values. That led to at least a few issues:
1) metadata will return incorrect information. For example type DECIMAL will be
returned as DECIMAL(32767, 0)
2) The same issue will be for TYPEOF function for DECIMAL column will be
returned DECIMAL(32767, 0)
To fix the issue we should amend restrictions for configurations that are
currently are not allowed to keep negative values and keep as special values
sign default precision and/or scale, or do the properties like a nullable.
was:
SQL standard says:
{code:java}
If or is not specified explicitly, then the corresponding
element of the descriptor effectively contains the null value.{code}
But we keep our default values. That led to at least a few issues:
1) metadata will return incorrect information. For example type DECIMAL will be
returned as DECIMAL(32767, 0)
2) The same issue will be for TYPEOF function for DECIMAL column will be
returned DECIMAL(32767, 0)
To fix the issue we should amend restrictions for configurations that are
currently are not allowed to keep negative values and keep as special values
sign default precision and/or scale, or do the properties like a nullable.
> Sql. The sign of the default values for precision and scale is not kept
> ---
>
> Key: IGNITE-18789
> URL: https://issues.apache.org/jira/browse/IGNITE-18789
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> SQL standard (P 4.4.1) says:
> {code:java}
> If or is not specified explicitly, then the corresponding
> element of the descriptor effectively contains the null value.{code}
> But we keep our default values. That led to at least a few issues:
> 1) metadata will return incorrect information. For example type DECIMAL will
> be returned as DECIMAL(32767, 0)
> 2) The same issue will be for TYPEOF function for DECIMAL column will be
> returned DECIMAL(32767, 0)
> To fix the issue we should amend restrictions for configurations that are
> currently are not allowed to keep negative values and keep as special values
> sign default precision and/or scale, or do the properties like a nullable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22789) Throw informative exception when both partitioned and replicated caches are participate in join operation
[ https://issues.apache.org/jira/browse/IGNITE-22789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867999#comment-17867999 ] Iurii Gerzhedovich commented on IGNITE-22789: - [~zstan] LGTM, thanks for the contribution > Throw informative exception when both partitioned and replicated caches are > participate in join operation > - > > Key: IGNITE-22789 > URL: https://issues.apache.org/jira/browse/IGNITE-22789 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.16 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > According to documentation in [1] join operations (H2 involved only) under > mixed partitioned vs replicated caches are possible only if number of > configured affinity partitions are equal. > For now it`s possible to join such a caches without any warning and as a > result - obtain erroneous results. It is necessary that an exception be > thrown in case of misconfiguration. > [1] https://issues.apache.org/jira/browse/IGNITE-8732 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22788) Sql. Support of FORMAT clause of the CAST operator
[
https://issues.apache.org/jira/browse/IGNITE-22788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22788:
Description:
Calcite 1.37 brings -support of FORMAT clause of the CAST operator -,
unfortunately, it doent's work automatically in AI3 and leads to assertion
during planning phase. E.g. for query
{code:java}
select cast('18-12-03' as date format 'YY-MM-DD'){code}
we got
{code:java}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3213)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3811)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3763)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1269)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1145)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:274)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:268)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:985)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:222)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:103)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:70)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.reduce(RexExecutorImpl.java:157)
at org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2274)
at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
at
org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
at
org.apache.calcite.tools.RelBuilder.lambda$project_$7(RelBuilder.java:2050)
{code}
Seems we need just synchronize all our code which was copy-pasted to us:
RexToLixTranslator, RexImpTable, e.t.c
was:
Calcite 1.37 brings [support of FORMAT clause of the CAST operator
|CALCITE-2980], unfortunately, it doent's work automatically in AI3 and leads
to assertion during planning phase. E.g. for query
{code:java}
select cast('18-12-03' as date format 'YY-MM-DD'){code}
we got
{code:java}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3213)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3811)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3763)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1269)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1145)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:274)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:268)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:985)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:222)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:103)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:70)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.reduce(RexExecutorImpl.java:157)
[jira] [Created] (IGNITE-22788) Sql. Support of FORMAT clause of the CAST operator
Iurii Gerzhedovich created IGNITE-22788:
---
Summary: Sql. Support of FORMAT clause of the CAST operator
Key: IGNITE-22788
URL: https://issues.apache.org/jira/browse/IGNITE-22788
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Iurii Gerzhedovich
Calcite 1.37 brings [support of FORMAT clause of the CAST operator
|CALCITE-2980], unfortunately, it doent's work automatically in AI3 and leads
to assertion during planning phase. E.g. for query
{code:java}
select cast('18-12-03' as date format 'YY-MM-DD'){code}
we got
{code:java}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3213)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3811)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3763)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1269)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1145)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:274)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:268)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:985)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:222)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:103)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:70)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.reduce(RexExecutorImpl.java:157)
at org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2274)
at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
at
org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
at
org.apache.calcite.tools.RelBuilder.lambda$project_$7(RelBuilder.java:2050)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22781) Cli. Incorrect question during connect to a node
Iurii Gerzhedovich created IGNITE-22781:
---
Summary: Cli. Incorrect question during connect to a node
Key: IGNITE-22781
URL: https://issues.apache.org/jira/browse/IGNITE-22781
Project: Ignite
Issue Type: Improvement
Components: cli
Reporter: Iurii Gerzhedovich
Try to run `connect` command in CLI, it shows a strange question
{code:java}
[defaultNode]> connect
You are already connected to the http://localhost:10300, do you want to connect
as ? [Y/n]
Connected to http://localhost:10300
[defaultNode]> {code}
Seems need to validate that node address has been provided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22716) Calcite engine. DECODE can't convert INT to DECIMAL
[
https://issues.apache.org/jira/browse/IGNITE-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22716:
Labels: calcite ise (was: calcite calcite3-required ise)
> Calcite engine. DECODE can't convert INT to DECIMAL
> ---
>
> Key: IGNITE-22716
> URL: https://issues.apache.org/jira/browse/IGNITE-22716
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproducer:
> {noformat}
> sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22778) Sql. DECODE can't convert INT to DECIMAL
[
https://issues.apache.org/jira/browse/IGNITE-22778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22778:
Labels: calcite ise (was: calcite calcite3-required ise)
> Sql. DECODE can't convert INT to DECIMAL
>
>
> Key: IGNITE-22778
> URL: https://issues.apache.org/jira/browse/IGNITE-22778
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Fix For: 2.17
>
>
> Reproducer:
> {noformat}
> sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22778) Sql. DECODE can't convert INT to DECIMAL
Iurii Gerzhedovich created IGNITE-22778:
---
Summary: Sql. DECODE can't convert INT to DECIMAL
Key: IGNITE-22778
URL: https://issues.apache.org/jira/browse/IGNITE-22778
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Iurii Gerzhedovich
Assignee: Aleksey Plekhanov
Fix For: 2.17
Reproducer:
{noformat}
sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
Fails with an exception:
{noformat}
java.lang.AssertionError: For conversion to decimal,
ConverterUtils#convertToDecimal method should be used instead.
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
~[classes/:?]
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
~[classes/:?]
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22716) Calcite engine. DECODE can't convert INT to DECIMAL
[
https://issues.apache.org/jira/browse/IGNITE-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22716:
Labels: calcite calcite3-required ise (was: calcite ise)
> Calcite engine. DECODE can't convert INT to DECIMAL
> ---
>
> Key: IGNITE-22716
> URL: https://issues.apache.org/jira/browse/IGNITE-22716
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required, ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproducer:
> {noformat}
> sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22777) Improve CLI usability
[
https://issues.apache.org/jira/browse/IGNITE-22777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22777:
Description:
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest:
# As a user, I should know that cluster need to be initialized. The first
action in CLI is to connect to a node. We know that cluster not inited, let's
show the suggestion to the user that it is required and show suggestions on
what needs to do. And do it for any command required initialized cluster,
instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
was:
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest: # As a user, I should know that cluster need to be initialized.
The first action in CLI is to connect to a node. We know that cluster not
inited, let's show the suggestion to the user that it is required and show
suggestions on what needs to do. And do it for any command required initialized
cluster, instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
> Improve CLI usability
> -
>
> Key: IGNITE-22777
> URL: https://issues.apache.org/jira/browse/IGNITE-22777
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> I've tried to use CLI in AI3, it's cool and a big improvement in usability
> compared to AI2.
> However, there are many places to make it more user-friendly and look better.
> What I suggest:
> # As a user, I should know that cluster need to be initialized. The first
> action in CLI is to connect to a node. We know that cluster not inited, let's
> show the suggestion to the user that it is required and show suggestions on
> what needs to do. And do it for any command required initialized cluster,
> instead of show strange errors like {{196609 Trace ID:
> c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
> # When I see the usage of cluster init I see 2 mandatory parameters, but it
> is hard to look, at due to them mixed with optional parameters - let's move
> all mandatory parameters to the beginning. It related to any CLI commands,
> not only to `cluster init`
> # For all commands let's add the following options: #
> ## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage
> section
> ## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
> ## `descriptionHeading = "%n"` to split the first and the second parts
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22777) Improve CLI usability
Iurii Gerzhedovich created IGNITE-22777:
---
Summary: Improve CLI usability
Key: IGNITE-22777
URL: https://issues.apache.org/jira/browse/IGNITE-22777
Project: Ignite
Issue Type: Improvement
Reporter: Iurii Gerzhedovich
I've tried to use CLI in AI3, it's cool and a big improvement in usability
compared to AI2.
However, there are many places to make it more user-friendly and look better.
What I suggest: # As a user, I should know that cluster need to be initialized.
The first action in CLI is to connect to a node. We know that cluster not
inited, let's show the suggestion to the user that it is required and show
suggestions on what needs to do. And do it for any command required initialized
cluster, instead of show strange errors like {{196609 Trace ID:
c5bc2dc3-7ed8-4191-b65a-559db9e680b1}}
# When I see the usage of cluster init I see 2 mandatory parameters, but it is
hard to look, at due to them mixed with optional parameters - let's move all
mandatory parameters to the beginning. It related to any CLI commands, not only
to `cluster init`
# For all commands let's add the following options: #
## {{`requiredOptionMarker = '*'`}} to mark mandatory options in usage section
## `{{{}usageHelpAutoWidth = true{}}} `to use width of user terminal
## `descriptionHeading = "%n"` to split the first and the second parts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22635) Sql. Unable to optimize plan error for input out of range
[
https://issues.apache.org/jira/browse/IGNITE-22635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22635:
Description:
In some cases, we can't make a query plan in case input values is out of range
of destination.
For example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT)");
long a = Long.MAX_VALUE-1000;
BigDecimal val = BigDecimal.valueOf(a + ((double) a /
1000)).add(BigDecimal.valueOf(Long.MAX_VALUE));
igniteSql().execute(null, "INSERT INTO TEST VALUES (" + val + ", " + val +
")");
}{code}
—
{code:java}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:15fcd9d1-e906-418d-95c5-b5cbde5fb6eb Unable to optimize plan due to
internal error
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:166)
at
org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:405)
at
org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:393)
at
org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:377)
at
org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.assertPlan(AbstractPlannerTest.java:499)
at
org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.assertPlan(AbstractPlannerTest.java:488)
at
org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.assertPlan(AbstractPlannerTest.java:469)
at
org.apache.ignite.internal.sql.engine.planner.datatypes.NumericInsertSourcesCoercionTest.insert1(NumericInsertSourcesCoercionTest.java:94)
at java.base/java.lang.reflect.Method.invoke(Method.java:580) at
java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at
java.base/java.util.ArrayList.forEach(ArrayList.java:1596)Caused by:
java.lang.ArithmeticException: BIGINT out of range at
org.apache.ignite.internal.sql.engine.util.IgniteMath.checkNumberLongBounds(IgniteMath.java:486)
at
org.apache.ignite.internal.sql.engine.util.IgniteMath.convertToLongExact(IgniteMath.java:292)
at
org.apache.ignite.internal.sql.engine.util.Primitives.convertPrimitiveExact(Primitives.java:127)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateLiteral(RexToLixTranslator.java:916)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLiteral(RexToLixTranslator.java:1164)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLiteral(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexLiteral.accept(RexLiteral.java:1251) at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1142)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77) at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1275)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1262)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1142)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77) at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:274)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:268)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:982)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:222)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:103)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:70)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.reduce(RexExecutorImpl.java:157)
at org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2274)
at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
at org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
at
[jira] [Updated] (IGNITE-22635) Sql. Unable to optimize plan error for input out of range
[
https://issues.apache.org/jira/browse/IGNITE-22635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22635:
Description:
In some cases, we can't make a query plan in case input values is out of range
of destination.
For example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT)");
long a = Long.MAX_VALUE-1000;
BigDecimal val = BigDecimal.valueOf(a + ((double) a /
1000)).add(BigDecimal.valueOf(Long.MAX_VALUE));
igniteSql().execute(null, "INSERT INTO TEST VALUES (" + val + ", " + val +
")");
}{code}
—
{code:java}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:00bc7f29-ac6d-4ff0-a390-17d5414d600f Unable to optimize plan due to
internal error
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
at
org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:789)
at
org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:723)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:658)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
at
org.apache.ignite.internal.sql.api.IgniteSqlImpl.execute(IgniteSqlImpl.java:210)
at
org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.lambda$execute$1(PublicApiThreadingIgniteSql.java:65)
at
org.apache.ignite.internal.thread.PublicApiThreading.executeWithRole(PublicApiThreading.java:144)
at
org.apache.ignite.internal.thread.PublicApiThreading.execUserSyncOperation(PublicApiThreading.java:102)
at
org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.execute(PublicApiThreadingIgniteSql.java:65)
at
org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.t(ItSqlApiBaseTest.java:551)
at java.base/java.lang.reflect.Method.invoke(Method.java:580) at
java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at
java.base/java.util.ArrayList.forEach(ArrayList.java:1596)Caused by:
java.util.concurrent.CompletionException: org.apache.ignite.sql.SqlException:
IGN-CMN-65535 TraceId:00bc7f29-ac6d-4ff0-a390-17d5414d600f Unable to optimize
plan due to internal error at
org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$5(IgniteSqlImpl.java:379)
at
java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:990)
at
java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:974)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)Caused by:
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:00bc7f29-ac6d-4ff0-a390-17d5414d600f Unable to optimize plan due to
internal error at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:166)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.doOptimize(PrepareServiceImpl.java:578)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$7(PrepareServiceImpl.java:426)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
... 3 moreCaused by: java.lang.ArithmeticException: Value
1.7976931348623157E308 out of range at
org.apache.calcite.linq4j.tree.Primitive.checkRoundedRange(Primitive.java:383)
at
org.apache.calcite.linq4j.tree.Primitive.numberValue(Primitive.java:402) at
org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:575)at
org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
at
org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
at
org.apache.calcite.linq4j.tree.TernaryExpression.accept(TernaryExpression.java:47)
at
org.apache.calcite.linq4j.tree.Expressions.acceptExpressions(Expressions.java:3266)
at
org.apache.calcite.linq4j.tree.NewArrayExpression.accept(NewArrayExpression.java:49)
at org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:64)
at org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:455)
at org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:340)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexExecutorImpl.compile(RexExecutorImpl.java:116)
[jira] [Updated] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22722:
Epic Link: IGNITE-22587
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15080:
Epic Link: IGNITE-22700
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> I discovered the strange behavior of functions with several string
> parameters, which then returns one of these parameters. In this case, the
> returned parameter string is expanded with trailing spaces to the length of
> the longest string.
> {code:java}
> query T
> SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
>
> world - result is 'world ' - so we have extra trailing spaces from max
> length string parameter'blabla'{code}
> {code:java}
> query I
> SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
>
> GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces
> from max length string parameter 'Hewlett Packard'{code}
> see src/test/sql/function/generic/test_decode.test_ignore
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17864960#comment-17864960
]
Iurii Gerzhedovich commented on IGNITE-15080:
-
[~alex_pl] can I remove the assignee from you?
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> I discovered the strange behavior of functions with several string
> parameters, which then returns one of these parameters. In this case, the
> returned parameter string is expanded with trailing spaces to the length of
> the longest string.
> {code:java}
> query T
> SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
>
> world - result is 'world ' - so we have extra trailing spaces from max
> length string parameter'blabla'{code}
> {code:java}
> query I
> SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
>
> GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces
> from max length string parameter 'Hewlett Packard'{code}
> see src/test/sql/function/generic/test_decode.test_ignore
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22706) Sql. Unignore sql test related to group by alias
[ https://issues.apache.org/jira/browse/IGNITE-22706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22706: Epic Link: IGNITE-22700 > Sql. Unignore sql test related to group by alias > > > Key: IGNITE-22706 > URL: https://issues.apache.org/jira/browse/IGNITE-22706 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > AI3 has a few muted tests under IGNITE-14885 however the ticket related just > to AI3. > Let's unmute it and check what another issue we have here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22706) Sql. Unignore sql test related to group by alias
Iurii Gerzhedovich created IGNITE-22706: --- Summary: Sql. Unignore sql test related to group by alias Key: IGNITE-22706 URL: https://issues.apache.org/jira/browse/IGNITE-22706 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich AI3 has a few muted tests under IGNITE-14885 however the ticket related just to AI3. Let's unmute it and check what another issue we have here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18414) SQL. Cannot use BigInteger class as parameters for query
[
https://issues.apache.org/jira/browse/IGNITE-18414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-18414:
Epic Link: IGNITE-22700
> SQL. Cannot use BigInteger class as parameters for query
>
>
> Key: IGNITE-18414
> URL: https://issues.apache.org/jira/browse/IGNITE-18414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> imple broken scenario looks as
> {code:java}
> assertQuery("SELECT typeof( ?
> )").withParams(BigInteger.valueOf(1)).returns(toSqlType(NUMBER)).check();{code}
> In the case we have the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
> Expected: [NUMBER]
> Actual: [RecordType()] {code}
> Let's use NUMERIC SQL type for BigInteger.
> I check a bit more and found strange in some cases:
> 1. assertQuery("SELECT UPPER(TYPEOF(? + ?))").withParams(1, 1d) : INTEGER
> 2. assertQuery("SELECT UPPER(TYPEOF(? + ?))").withParams(1d, 1) : DOUBLE ???
> is it ok
> 3. assertQuery("SELECT UPPER(TYPEOF(?::FLOAT + ?))").withParams(1, 1) : FLOAT
> 4. assertQuery("SELECT UPPER(TYPEOF(? + ?::DOUBLE))").withParams(1, 1d) :
> DOUBLE ??? change from 1 only by cast - changes return, is it ok
> 5. assertQuery("SELECT UPPER(TYPEOF(?::FLOAT + ?))").withParams(1, 1d) :
> FLOAT ??? i expect double here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20889) Sql. Change type derivation for literals and expressions for overflowed BIGINT
[
https://issues.apache.org/jira/browse/IGNITE-20889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-20889:
Epic Link: IGNITE-22700
> Sql. Change type derivation for literals and expressions for overflowed BIGINT
> --
>
> Key: IGNITE-20889
> URL: https://issues.apache.org/jira/browse/IGNITE-20889
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> After [1] will be merged, it become possible to control overflow with numeric
> operations, there are 3 places in code (will be notified under this issue)
> which have been changed but seems it`s all due to partially incorrect
> (calcite?) implementation. I spend a bit time and found that case with
> overflowed BIGINT insertion: *ItDmlTest#testInsertValueOverflow* can be fixed
> by correct implementing: *SqlNumericLiteral#createSqlType*, i fast check and
> seems it will began work properly well, without additional code changes (all
> core manipulations in scope of [1] can be reverted). The second case:
> insertion for overflowed SUM of BIGINT additional fix need to be done,
> check: *SqlValidatorImpl#getValidatedNodeType*
> Further research is required here.
> [1] https://issues.apache.org/jira/browse/IGNITE-18662
> Just for note, for all above checks - i made dirty hack here:
> IgniteSqlValidator#deriveType
> {code:java}
> if (expr instanceof SqlNumericLiteral) {
> SqlNumericLiteral expr0 = (SqlNumericLiteral) expr;
> if (expr0.toValue().length() > 10 && expr0.getTypeName() ==
> SqlTypeName.DECIMAL) {
> return typeFactory.createSqlType(
> SqlTypeName.DECIMAL,
> requireNonNull(20, "prec"),
> 0);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22697) Sql. Comparison on BIGINT cast brings overflow
[
https://issues.apache.org/jira/browse/IGNITE-22697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22697:
Epic Link: IGNITE-22700
> Sql. Comparison on BIGINT cast brings overflow
> --
>
> Key: IGNITE-22697
> URL: https://issues.apache.org/jira/browse/IGNITE-22697
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> create table tbl(v BIGINT);
> insert into tbl values(9223372036854775807);
> SELECT * FROM tbl WHERE v < 9223372036854775808::DECIMAL(19, 0);
> {noformat}
> will compile into:
> {noformat}
> try {
> final Long input_value = (Long) ctx.rowHandler().get(0, in1);
> final java.math.BigDecimal cast_value = input_value == null ? null :
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal(input_value.longValue(),
> 19, 0);
> out.addField(cast_value == null ? null :
> Boolean.valueOf(org.apache.calcite.runtime.SqlFunctions.lt(cast_value,
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal("-9223372036854775808",
> 19, 0;
> } catch (Exception e) {
> throw new org.apache.ignite.sql.SqlException(
> 262151,
> e);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15605) Calcite. Unexpected result with aggregate inside subquery.
[
https://issues.apache.org/jira/browse/IGNITE-15605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15605:
Epic Link: IGNITE-22700
> Calcite. Unexpected result with aggregate inside subquery.
> --
>
> Key: IGNITE-15605
> URL: https://issues.apache.org/jira/browse/IGNITE-15605
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> {noformat}
> statement ok
> CREATE TABLE integers(i INTEGER)
> statement ok
> INSERT INTO integers VALUES (1), (2), (3), (NULL)
> query R SELECT i, SUM(i), (SELECT SUM(i)+SUM(i1.i) FROM integers) FROM
> integers i1 GROUP BY i ORDER BY i;
>
> 1 1.00 10
> 2 2.00 14
> 3 3.00 18
> NULL NULL NULL {noformat}
> {noformat}
> /subquery/scalar/test_correlated_aggregate_subquery.test_ignore
> /subquery/scalar/test_varchar_correlated_subquery.test_ignore
> {noformat}
>
> {code:java}
> Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast
> to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at SC.execute(Unknown Source)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:654)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.StorageScanNode.push(StorageScanNode.java:197)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.StorageScanNode$SubscriberImpl.lambda$onComplete$2(StorageScanNode.java:303)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:315){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15570) JOIN with USING with common column names failed.
[
https://issues.apache.org/jira/browse/IGNITE-15570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15570:
Epic Link: IGNITE-22700
> JOIN with USING with common column names failed.
>
>
> Key: IGNITE-15570
> URL: https://issues.apache.org/jira/browse/IGNITE-15570
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> {noformat}
> statement ok
> CREATE TABLE t1 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t1 VALUES (1,2,3)
> statement ok
> CREATE TABLE t2 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t2 VALUES (1,2,3), (2,2,4), (1,3,4)
> query I
> SELECT a+1 FROM t1 JOIN t2 USING(a) ORDER BY a
>
> 2
> 2
> {noformat}
> failed with
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 46:
> Column 'A' is ambiguous
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> {noformat}
> {noformat}
> /join/inner/test_using_join.test[_ignore]
> {noformat}
> checked with mysql - all ok there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22295) Sql. Allow comparable types for common columns in NATURAL / USING join conditions
[ https://issues.apache.org/jira/browse/IGNITE-22295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22295: Epic Link: IGNITE-22700 > Sql. Allow comparable types for common columns in NATURAL / USING join > conditions > - > > Key: IGNITE-22295 > URL: https://issues.apache.org/jira/browse/IGNITE-22295 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Pavel Pereslegin >Priority: Minor > Labels: ignite-3 > > As type coercion for NATURAL/USING join conditions is not invoked, such > queries produce incorrect results when column types of common columns do not > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22700) Improve SQL quality in AI3
[ https://issues.apache.org/jira/browse/IGNITE-22700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22700: Description: We have many bugs and discrepancies with SQL Standard. Let's combine under the epic part of such issues, to divide all works into parts. was:We have many bugs and discrepancies with SQL Standard. Let's combine under the epic part of such issues, to divide all works into parts. > Improve SQL quality in AI3 > -- > > Key: IGNITE-22700 > URL: https://issues.apache.org/jira/browse/IGNITE-22700 > Project: Ignite > Issue Type: Epic > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have many bugs and discrepancies with SQL Standard. Let's combine under > the epic part of such issues, to divide all works into parts. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22703) Sql. Low performance for select with mixed projection
[ https://issues.apache.org/jira/browse/IGNITE-22703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22703: Labels: ignite-3 (was: sql) > Sql. Low performance for select with mixed projection > - > > Key: IGNITE-22703 > URL: https://issues.apache.org/jira/browse/IGNITE-22703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have low performance in case we reorder columns in SELECT statement. > Below result of my laptop for SELECT from a table with 600k rows. The first > one is to select all columns in the same order as was declared during > creating the table, the second one - reorder the first and the second columns > in the select list. > > ||Benchmark||(queryId) ||Mode||Cnt||Score||Error||Units|| > |TpchBenchmark.run |1|avgt|20|206.522|± 1.167|ms/op| > |TpchBenchmark.run |2|avgt|20|784.153|± 1.792|ms/op| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22703) Sql. Low performance for select with mixed projection
Iurii Gerzhedovich created IGNITE-22703: --- Summary: Sql. Low performance for select with mixed projection Key: IGNITE-22703 URL: https://issues.apache.org/jira/browse/IGNITE-22703 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich We have low performance in case we reorder columns in SELECT statement. Below result of my laptop for SELECT from a table with 600k rows. The first one is to select all columns in the same order as was declared during creating the table, the second one - reorder the first and the second columns in the select list. ||Benchmark||(queryId) ||Mode||Cnt||Score||Error||Units|| |TpchBenchmark.run |1|avgt|20|206.522|± 1.167|ms/op| |TpchBenchmark.run |2|avgt|20|784.153|± 1.792|ms/op| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22702) Rewrite CREATE TABLE FROM QUERY RESULT in tests.
Iurii Gerzhedovich created IGNITE-22702: --- Summary: Rewrite CREATE TABLE FROM QUERY RESULT in tests. Key: IGNITE-22702 URL: https://issues.apache.org/jira/browse/IGNITE-22702 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich We have muted a bunch of tests under IGNITE-17268, as we don't support CREATE TABLE from a query result. We could quickly unmute such tests just to rewrite them to separate create table statement and insert statement. Let's unmute all such tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22580) Sql. Add planner test to verify numeric type coercion for CASE operator
[ https://issues.apache.org/jira/browse/IGNITE-22580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22580: Epic Link: IGNITE-22700 > Sql. Add planner test to verify numeric type coercion for CASE operator > --- > > Key: IGNITE-22580 > URL: https://issues.apache.org/jira/browse/IGNITE-22580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for CASE operator. The tests > should be as easy as possible, every test case must answer a question "what > are expected types of each set operation when we use a given numeric type > pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22655) Sql. incorrect error for quoted SQL
[
https://issues.apache.org/jira/browse/IGNITE-22655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22655:
Epic Link: IGNITE-22700
> Sql. incorrect error for quoted SQL
> ---
>
> Key: IGNITE-22655
> URL: https://issues.apache.org/jira/browse/IGNITE-22655
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> If a query is fully quoted it leads to an error message that the length must
> be less than 128 characters.
> Froexample:
> {code:java}
> "CREATE TABLE Trade (id long, buyer_id int, symbol varchar, order_quantity
> int, bid_price double, trade_type varchar, order_date timestamp, PRIMARY
> KEY(id, buyer_id)) COLOCATE BY buyer_id";{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22283) Get rid of not supported native types
[ https://issues.apache.org/jira/browse/IGNITE-22283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-22283: --- Assignee: (was: Iurii Gerzhedovich) > Get rid of not supported native types > - > > Key: IGNITE-22283 > URL: https://issues.apache.org/jira/browse/IGNITE-22283 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we have NativeTypeSpec.NUMBER and NativeTypeSpec.BITMASK which > required support during development, but we still have no support of them. > Let's remove both types and cleanup code where it used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22580) Sql. Add planner test to verify numeric type coercion for CASE operator
[ https://issues.apache.org/jira/browse/IGNITE-22580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-22580: --- Assignee: (was: Iurii Gerzhedovich) > Sql. Add planner test to verify numeric type coercion for CASE operator > --- > > Key: IGNITE-22580 > URL: https://issues.apache.org/jira/browse/IGNITE-22580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for CASE operator. The tests > should be as easy as possible, every test case must answer a question "what > are expected types of each set operation when we use a given numeric type > pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22579) Sql. Add planner test to verify numeric type coercion for IN operator
[ https://issues.apache.org/jira/browse/IGNITE-22579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-22579: --- Assignee: (was: Iurii Gerzhedovich) > Sql. Add planner test to verify numeric type coercion for IN operator > - > > Key: IGNITE-22579 > URL: https://issues.apache.org/jira/browse/IGNITE-22579 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for IN operator. The tests > should be as easy as possible, every test case must answer a question "what > are expected types of each set operation when we use a given numeric type > pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17373) Sql. Investigate interval types for Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-17373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-17373:
Epic Link: IGNITE-22700
> Sql. Investigate interval types for Ignite 3
>
>
> Key: IGNITE-17373
> URL: https://issues.apache.org/jira/browse/IGNITE-17373
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> For now, interval types like {{Duration}} and {{Period}} is not supported.
> Let's read SQL standard and describe which types related to Interval types in
> document. Also need to create separate task to add native support for
> mentioned types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20835) Sql. Update statements incorrectly use scalar subqueries in target columns
[
https://issues.apache.org/jira/browse/IGNITE-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-20835:
Epic Link: IGNITE-22700
> Sql. Update statements incorrectly use scalar subqueries in target columns
>
>
> Key: IGNITE-20835
> URL: https://issues.apache.org/jira/browse/IGNITE-20835
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Update statements incorrectly use scalar subqueries in target columns, the
> issues stems from the fact that scalar subquery in UPDATE are not wrapped in
> `SINGLE_VAL` aggregate.
> Examples:
> {code:java}
> @Test
> public void ddml2() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> INTEGER);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // works
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
> WHERE id = 1");
> // Should fail, because a subquery returns more than 1 result.
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE
> id >= 2");
> }
> UPDATEs in MERGE statement are also affect by this issue:
> {code:java}
> @Test
> public void ddml2_1() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> INTEGER);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // Fails with PK unique constraint is violated
> sql("MERGE INTO vals USING other_vals ON vals.id = other_vals.id "
> + "WHEN MATCHED THEN UPDATE SET val = (SELECT other_val FROM
> other_vals WHERE id > 1) "
> + "WHEN NOT MATCHED THEN INSERT (id, val) VALUES (100, -1)");
> }
> {code}
> {code}
> If we change val type to BIGINT we get another error:
> {code:java}
> @Test
> public void ddml3() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> BIGINT);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // works
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
> WHERE id = 1");
> // Error
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE
> id >= 2");
> }
> {code}
> Error:
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:297)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:294)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:453)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:360)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:241)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5112)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5219)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:187)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
>
[jira] [Updated] (IGNITE-18362) Sql. Unexpected date time output formatting.
[
https://issues.apache.org/jira/browse/IGNITE-18362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-18362:
Epic Link: IGNITE-22700
> Sql. Unexpected date time output formatting.
>
>
> Key: IGNITE-18362
> URL: https://issues.apache.org/jira/browse/IGNITE-18362
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Unexpected formatting i.e. :
> {code:java}
> SELECT TIMESTAMP '2008-01-01 00:00:01'
> expected=2008-01-01 00:00:01.0, actual=2008-01-01T00:00:01
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15567) Calcite. Support REPEAT functionality or remove it from tests.
[
https://issues.apache.org/jira/browse/IGNITE-15567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15567:
Epic Link: IGNITE-22700
> Calcite. Support REPEAT functionality or remove it from tests.
> --
>
> Key: IGNITE-15567
> URL: https://issues.apache.org/jira/browse/IGNITE-15567
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> Now failed:
> {noformat}
> CREATE TABLE test2 AS SELECT * FROM repeat(1, 10*1024) t1(b), (SELECT 10)
> t2(c);
> {noformat}
> {noformat}
> /join/inner/test_join_duplicates.test[_ignored]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18883) Bug. Potentially incorrect definition of rows to insert for MERGE
[
https://issues.apache.org/jira/browse/IGNITE-18883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-18883:
Epic Link: IGNITE-22700
> Bug. Potentially incorrect definition of rows to insert for MERGE
> -
>
> Key: IGNITE-18883
> URL: https://issues.apache.org/jira/browse/IGNITE-18883
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Currently we decide whether to insert row or to update row by taking a look
> at value at updateOffset. The problem here is that NULL can be a legit value,
> but we incorrectly put this row to insert collection:
> {code:java}
> // ModifyNode#splitMerge
> private Pair, List> splitMerge(List rows) {
> ...
> if (!hasUpsertSemantic) {
>...
> } else {
> ...
> for (RowT row : rows) {
> if (handler.get(updateColumnOffset, row) == null) {
> rowsToInsert.add(row);
> } else {
> rowsToUpdate.add(row);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21856) Unable to insert values with exponent values >=39 for FLOAT and REAL
[
https://issues.apache.org/jira/browse/IGNITE-21856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-21856:
Epic Link: IGNITE-22700
> Unable to insert values with exponent values >=39 for FLOAT and REAL
>
>
> Key: IGNITE-21856
> URL: https://issues.apache.org/jira/browse/IGNITE-21856
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Anatoli Karman
>Priority: Major
> Labels: ignite-3
>
> Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*})
> for FLOAT and REAL data type columns results in an error.
> *Please note that this issue is present only for IG3.*
>
> {*}Steps to reproduce{*}:
> - send an insert query where a value for REAL or FLOAT column is
> *{{3.4028235E39}}*
> {code:java}
> insert into test_e011_REAL (key_field, field1_REAL) values (3,
> 3.4028235E39);{code}
>
> *Expected result:*
> Data has been successfully inserted in the table.
> The data returned upon respective select query:
> {code:java}
> '3','Infinity'{code}
>
> *Actual result:*
> Data has not been inserted.
> The following error is present:
> {code:java}
> Character I is neither a decimal digit number, decimal point, nor "e"
> notation exponential mark.{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15583) Calcite. Column not found error with correlated sub query.
[
https://issues.apache.org/jira/browse/IGNITE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15583:
Epic Link: IGNITE-22700
> Calcite. Column not found error with correlated sub query.
> --
>
> Key: IGNITE-15583
> URL: https://issues.apache.org/jira/browse/IGNITE-15583
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required
>
> {noformat}
> statement ok
> CREATE TABLE integers(i INTEGER)
> statement ok
> INSERT INTO integers VALUES (1), (2), (3), (NULL)
> query IR
> SELECT (SELECT MAX(i) FROM integers) AS k, SUM(i) FROM integers GROUP BY k;
>
> 3 6.00
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 74:
> Column 'K' not found in any table
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> {noformat}
> {noformat}
> /subquery/any_all/test_uncorrelated_all_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19701) Type exception on insert into uuid columns with gen_random_uuid
[
https://issues.apache.org/jira/browse/IGNITE-19701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-19701:
Epic Link: IGNITE-22700
> Type exception on insert into uuid columns with gen_random_uuid
> ---
>
> Key: IGNITE-19701
> URL: https://issues.apache.org/jira/browse/IGNITE-19701
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Step to reproduce:
> {noformat}
> create table tdd(a uuid default gen_random_uuid, b int, primary key (a) );
> insert into tdd(b) values(22)
> {noformat}
> Expected result: row with autogenerated primary key a inserted
> Actual result:
> {noformat}
> [Code: 0, SQL State: 5] Exception while executing query [query=insert
> into tdd(b) values(22)]. Error message:Query remote fragment execution
> failed: nodeName=DropColumnsTest_cluster_1,
> queryId=e0a9b944-74a5-4d9d-a4a9-7962cb821c81, fragmentId=20,
> originalMessage=storageType is class java.util.UUID value must also be class
> java.util.UUID but it was: 1726917f-f47f-4ccc-94a0-59ac518e101b{noformat}
> It is possibly to insert row with generated UUID:
> {noformat}
> insert into tdd(a, b) values('1726917f-f47f-4ccc-94a0-59ac518e101b',
> 22){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15123) Calcite. Multi-tuple insert fails on validation
[
https://issues.apache.org/jira/browse/IGNITE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15123:
Epic Link: IGNITE-22700
> Calcite. Multi-tuple insert fails on validation
> ---
>
> Key: IGNITE-15123
> URL: https://issues.apache.org/jira/browse/IGNITE-15123
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently a query like below fails on validation step:
> {code:java}
> create table test(d date);
> insert into test values('1990-01-01'),(null);
> {code}
> The reason is an extra validation step for insert with several tuples. This
> validation checks that all tuples have the same degree and the types of the
> corresponding fields throughout all tuples have the same family.
> In the example above types are mismatched cause type of the first tuple is
> CHAR, and type of the second tuple is DATE (because it's derived from table).
> {noformat}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to validate query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:531)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:391)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:259)
> at
> org.apache.ignite.internal.processors.query.calcite.integration.AbstractDdlIntegrationTest.executeSql(AbstractDdlIntegrationTest.java:77)
> at
> org.apache.ignite.internal.processors.query.calcite.integration.TableDdlIntegrationTest.test(TableDdlIntegrationTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.calcite.tools.ValidationException:
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 18 to
> line 1, column 44: Values passed to VALUES operator must have compatible types
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.validate(IgnitePlanner.java:175)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareDml(ExecutionServiceImpl.java:601)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:565)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:514)
> ... 17 more
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 18 to line 1, column 44: Values passed to VALUES operator must have
> compatible types
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
> at
>
[jira] [Updated] (IGNITE-18667) sql. left outer join with correlated subquery fails
[
https://issues.apache.org/jira/browse/IGNITE-18667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-18667:
Epic Link: IGNITE-22700
> sql. left outer join with correlated subquery fails
> ---
>
> Key: IGNITE-18667
> URL: https://issues.apache.org/jira/browse/IGNITE-18667
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following queries must work but the fail:
> {code:java}
> # left outer join on arbitrary correlated subquery
> statement ok
> SELECT * FROM integers s1 LEFT OUTER JOIN integers s2 ON (SELECT CASE WHEN
> s1.i+s2.i>10 THEN TRUE ELSE FALSE END) ORDER BY s1.i;
> {code}
> Expected:
> {code:java}
> i i
> 1 null
> 2 null
> 3 null
> null null
> {code}
> Actual:
> {code:java}
> Caused by: java.lang.AssertionError: All correlation variables should resolve
> to the same namespace. Prev
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@7f74c84c, new
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@11b2d99c
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:3006)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2916)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4865)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4930)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3253)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3173)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2392)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2280)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:694)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:675)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3737)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlToRelConvertor.convertQueryRecursive(IgniteSqlToRelConvertor.java:68)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:595)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22314) Sql. Incorrect result while using ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-22314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22314:
Epic Link: IGNITE-22700
> Sql. Incorrect result while using ALL operator.
> ---
>
> Key: IGNITE-22314
> URL: https://issues.apache.org/jira/browse/IGNITE-22314
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (1), (2), (3), (NULL);
> SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i
> IS NULL) FROM integers i1 ORDER BY i;
> the same for:
> SELECT i=ALL(SELECT i FROM integers WHERE i=i1.i OR i IS NULL) FROM integers
> i1 ORDER BY i;{noformat}
> returns incorrect result, need to be four NULL`s but four 'true' will return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14540) Calcite engine. Support correlated subquery in having
[
https://issues.apache.org/jira/browse/IGNITE-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-14540:
Epic Link: IGNITE-22700
> Calcite engine. Support correlated subquery in having
> --
>
> Key: IGNITE-14540
> URL: https://issues.apache.org/jira/browse/IGNITE-14540
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Correlated subquery in having isn't supported now.
> Test: {{aggregate/having/test_corel_subquery_in_having.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19402) Sql. Incorrect validation for query contains aggregates by outer query
[
https://issues.apache.org/jira/browse/IGNITE-19402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-19402:
Epic Link: IGNITE-22700
> Sql. Incorrect validation for query contains aggregates by outer query
> --
>
> Key: IGNITE-19402
> URL: https://issues.apache.org/jira/browse/IGNITE-19402
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: calcite2-required, ignite-3
>
> Sql engine consider incorrect queries which have aggregate function for outer
> query in WHERE clause. For example few queries in
> sql/subquery/any_all/test_correlated_any_all.test are fails:
> {code:java}
> SELECT (SELECT SUM(i)+SUM(i1.i) FROM integers)>ANY(SELECT i FROM integers
> WHERE i>MIN(i1.i)) FROM integers i1;
> SELECT SUM(i)>ANY(SELECT i FROM integers WHERE i>MIN(i1.i)) FROM integers i1;
> SELECT MIN(i)>ANY(SELECT i FROM integers WHERE i>MIN(i1.i)) FROM integers
> i1;{code}
> Validation error looks as
> {noformat}
> Aggregate expression is illegal in WHERE clause{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15004) Calcite engine. LIKE ESCAPE fails with empty escape string
[
https://issues.apache.org/jira/browse/IGNITE-15004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15004:
Epic Link: IGNITE-22700
> Calcite engine. LIKE ESCAPE fails with empty escape string
> --
>
> Key: IGNITE-15004
> URL: https://issues.apache.org/jira/browse/IGNITE-15004
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Minor
>
> {{SELECT '%_' LIKE '%_' ESCAPE ''}}
> error:
> {code}
> class org.apache.ignite.IgniteException: Unexpected exception
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:244)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.RuntimeException: Invalid escape character ''
> at org.apache.calcite.runtime.Like.invalidEscapeCharacter(Like.java:104)
> at org.apache.calcite.runtime.Like.sqlToRegexLike(Like.java:56)
> at org.apache.calcite.runtime.SqlFunctions.like(SqlFunctions.java:594)
> at SC.execute(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ProjectNode.push(ProjectNode.java:63)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:239)
> ... 4 more
> {code}
> Test:
> {{function/string/test_like_escape.test}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15582) Calcite. Numerous errors with any\all scalars.
[
https://issues.apache.org/jira/browse/IGNITE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15582:
Epic Link: IGNITE-22700
> Calcite. Numerous errors with any\all scalars.
> --
>
> Key: IGNITE-15582
> URL: https://issues.apache.org/jira/browse/IGNITE-15582
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> {{ /subquery/any_all/test_scalar_any_all.test[_ignore] }}
> {noformat}
> SELECT 1 = ALL(SELECT 1)
> {noformat}
> {noformat}
> Unexpected error at query optimizer.
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteSome(SubQueryRemoveRule.java:162)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:92)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.matchProject(SubQueryRemoveRule.java:603)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.access$200(SubQueryRemoveRule.java:71)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule$Config.lambda$static$1(SubQueryRemoveRule.java:685)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.onMatch(SubQueryRemoveRule.java:82)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> {noformat}
> {noformat}
> SELECT 1 = ALL(SELECT NULL)
> {noformat}
> {noformat}
> Unexpected error at query optimizer.
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteSome(SubQueryRemoveRule.java:162)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:92)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.matchProject(SubQueryRemoveRule.java:603)
> {noformat}
> {noformat}
> SELECT 1 IN (SELECT NULL)
> {noformat}
> {noformat}
> Unexpected error at query optimizer.
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(BOOLEAN NOT NULL EXPR$0) NOT NULL
> converted type:
> RecordType(BOOLEAN EXPR$0) NOT NULL
> rel:
> LogicalProject(EXPR$0=[IN(1, {
> LogicalValues(tuples=[[{ null }]])
> })])
> LogicalValues(tuples=[[{ 0 }]])
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:485)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:600)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:214)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22417) Sql. Validator accepts f(BIGINT) but SQL runtime does not define f(long) it has f(int)
[
https://issues.apache.org/jira/browse/IGNITE-22417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22417:
Epic Link: IGNITE-22700
> Sql. Validator accepts f(BIGINT) but SQL runtime does not define f(long) it
> has f(int)
> --
>
> Key: IGNITE-22417
> URL: https://issues.apache.org/jira/browse/IGNITE-22417
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Calcite uses TypeFamilies in a lot of places to define types of function
> arguments.
> This leads to a problem when a function that only accepts INTEGER type also
> accepts BIGINT type, but runtime does not have an implementation of a
> function that accepts long (because there can be no sense in doing so),
> causing a runtime error.
> *Example*:
> A function *f* can be called with TINYINT, SMALLINT, and INTEGER, but should
> be rejected by the validation when called with BIGINT:
> {noformat}
> Descriptor: F()
> Runtime: Fs.f(int)
> {noformat}
> Validator accepts a call to f(BIGINT) since BIGINT is a part of INTEGER type
> family.
> But f(long) is not defined in runtime, so java.lang.NoSuchMethodException:
> Fs.f(long) is thrown when a query get executed.
> *Expected behaviour*: when a function does not accept BIGINTs, then the
> validator should return an error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15001) Calcite engine. Sort out tests for REGEXP_REPLACE function
[
https://issues.apache.org/jira/browse/IGNITE-15001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15001:
Epic Link: IGNITE-22700
> Calcite engine. Sort out tests for REGEXP_REPLACE function
> --
>
> Key: IGNITE-15001
> URL: https://issues.apache.org/jira/browse/IGNITE-15001
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> The REGEXP_REPLACE function is implemented at the calcite but behavior
> differs with Postgres.
> Needs to investigate: change the function behavior or change the tests.
> Tests:
> {{function/string/regex_replace.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19890) Sql. VARCHAR. SUBSTRING function call with length greater than INT, triggers java.lang.NoSuchMethodException
[
https://issues.apache.org/jira/browse/IGNITE-19890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-19890:
Epic Link: IGNITE-22700
> Sql. VARCHAR. SUBSTRING function call with length greater than INT, triggers
> java.lang.NoSuchMethodException
>
>
> Key: IGNITE-19890
> URL: https://issues.apache.org/jira/browse/IGNITE-19890
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> The following query results in java.lang.NoSuchMethodException:
> org.apache.calcite.runtime.SqlFunctions.substring(java.lang.String, int, long)
> {code:java}
> assertQuery("SELECT Substring('abc' from 2 for 2147483650)").check();
> {code}
> *Error*
> {code:java}
> Caused by: java.lang.RuntimeException: while resolving method
> 'substring[class java.lang.String, int, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.call(EnumUtils.java:676)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$MethodImplementor.call(RexImpTable.java:2575)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$MethodImplementor.implementSafe(RexImpTable.java:2556)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3624)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3582)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1252)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:114)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1128)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:114)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:275)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:269)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:968)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:223)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:515)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.lambda$scalar$3(ExpressionFactoryImpl.java:448)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.scalar(ExpressionFactoryImpl.java:447)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.project(ExpressionFactoryImpl.java:265)
> at
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:214)
> at
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:119)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteProject.accept(IgniteProject.java:87)
> at
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:776)
> at
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:791)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.executeFragment(ExecutionServiceImpl.java:537)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$submitFragment$8(ExecutionServiceImpl.java:611)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
>
[jira] [Created] (IGNITE-22700) Improve SQL quality in AI3
Iurii Gerzhedovich created IGNITE-22700: --- Summary: Improve SQL quality in AI3 Key: IGNITE-22700 URL: https://issues.apache.org/jira/browse/IGNITE-22700 Project: Ignite Issue Type: Epic Components: sql Reporter: Iurii Gerzhedovich We have many bugs and discrepancies with SQL Standard. Let's combine under the epic part of such issues, to divide all works into parts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15624) Calcite. Support different connections in logical tests.
[
https://issues.apache.org/jira/browse/IGNITE-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15624:
Description:
As of now, we have a bunch of sql logic tests that require support for
different transactional connections, i.e: *con1, con2* and so on
{noformat}
statement ok con1
CREATE TABLE test (a VARCHAR);
query I con2
SELECT * FROM test ORDER BY a
NULL
NULL
1
3
{noformat}
{noformat}
/sql/update/*{noformat}
Let's decide whether we should add support for the feature or eliminate the
tests with extract cases that we don't have in other tests.
was:
As of now we have bunch of sql logic tests wiSupport different transactional
connections in tests, i.e: *con1, con2* and so on
{noformat}
statement ok con1
CREATE TABLE test (a VARCHAR);
query I con2
SELECT * FROM test ORDER BY a
NULL
NULL
1
3
{noformat}
{noformat}
/sql/update/*
{noformat}
> Calcite. Support different connections in logical tests.
>
>
> Key: IGNITE-15624
> URL: https://issues.apache.org/jira/browse/IGNITE-15624
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now, we have a bunch of sql logic tests that require support for
> different transactional connections, i.e: *con1, con2* and so on
> {noformat}
> statement ok con1
> CREATE TABLE test (a VARCHAR);
> query I con2
> SELECT * FROM test ORDER BY a
>
> NULL
> NULL
> 1
> 3
> {noformat}
> {noformat}
> /sql/update/*{noformat}
> Let's decide whether we should add support for the feature or eliminate the
> tests with extract cases that we don't have in other tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15624) Calcite. Support different connections in logical tests.
[
https://issues.apache.org/jira/browse/IGNITE-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15624:
Description:
As of now we have many sql logic tests wiSupport different transactional
connections in tests, i.e: *con1, con2* and so on
{noformat}
statement ok con1
CREATE TABLE test (a VARCHAR);
query I con2
SELECT * FROM test ORDER BY a
NULL
NULL
1
3
{noformat}
{noformat}
/sql/update/*
{noformat}
was:
Support different transactional connections in tests, i.e: *con1, con2* and so
on
{noformat}
statement ok con1
CREATE TABLE test (a VARCHAR);
query I con2
SELECT * FROM test ORDER BY a
NULL
NULL
1
3
{noformat}
{noformat}
/sql/update/*
{noformat}
> Calcite. Support different connections in logical tests.
>
>
> Key: IGNITE-15624
> URL: https://issues.apache.org/jira/browse/IGNITE-15624
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now we have many sql logic tests wiSupport different transactional
> connections in tests, i.e: *con1, con2* and so on
> {noformat}
> statement ok con1
> CREATE TABLE test (a VARCHAR);
> query I con2
> SELECT * FROM test ORDER BY a
>
> NULL
> NULL
> 1
> 3
> {noformat}
> {noformat}
> /sql/update/*
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15624) Calcite. Support different connections in logical tests.
[
https://issues.apache.org/jira/browse/IGNITE-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-15624:
Description:
As of now we have bunch of sql logic tests wiSupport different transactional
connections in tests, i.e: *con1, con2* and so on
{noformat}
statement ok con1
CREATE TABLE test (a VARCHAR);
query I con2
SELECT * FROM test ORDER BY a
NULL
NULL
1
3
{noformat}
{noformat}
/sql/update/*
{noformat}
was:
As of now we have many sql logic tests wiSupport different transactional
connections in tests, i.e: *con1, con2* and so on
{noformat}
statement ok con1
CREATE TABLE test (a VARCHAR);
query I con2
SELECT * FROM test ORDER BY a
NULL
NULL
1
3
{noformat}
{noformat}
/sql/update/*
{noformat}
> Calcite. Support different connections in logical tests.
>
>
> Key: IGNITE-15624
> URL: https://issues.apache.org/jira/browse/IGNITE-15624
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now we have bunch of sql logic tests wiSupport different transactional
> connections in tests, i.e: *con1, con2* and so on
> {noformat}
> statement ok con1
> CREATE TABLE test (a VARCHAR);
> query I con2
> SELECT * FROM test ORDER BY a
>
> NULL
> NULL
> 1
> 3
> {noformat}
> {noformat}
> /sql/update/*
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22687) Do not use common system thread pool in SQL
[ https://issues.apache.org/jira/browse/IGNITE-22687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22687: Component/s: sql > Do not use common system thread pool in SQL > --- > > Key: IGNITE-22687 > URL: https://issues.apache.org/jira/browse/IGNITE-22687 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > Currently, IgniteSqlImpl#processCursor() has the following line: > cursor.nextResult().whenCompleteAsync(this::processCursor); > This schedules subsequent processCursor() invocation to be executed in the > system common ForkJoinPool, which is dangerous because the pool might bee > exhausted (starved) by the user, and SQL execution could suffer. > It is suggested to use some Ignite-internal thread pool here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22681) Get rid of Session mention in AI3
Iurii Gerzhedovich created IGNITE-22681: --- Summary: Get rid of Session mention in AI3 Key: IGNITE-22681 URL: https://issues.apache.org/jira/browse/IGNITE-22681 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich After `Session` was removed from AI3 code (IGNITE-21669) we still have a few place that mention. Let's find all the places and clean it up. For example such places: docs/_docs/developers-guide/clients/java.adoc docs/_docs/quick-start/embedded-mode.adoc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22639) Sql. Different casts for literals and for dynamic parameters
[
https://issues.apache.org/jira/browse/IGNITE-22639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich resolved IGNITE-22639.
-
Resolution: Cannot Reproduce
It's already fixed and doesn't reproduce.
> Sql. Different casts for literals and for dynamic parameters
>
>
> Key: IGNITE-22639
> URL: https://issues.apache.org/jira/browse/IGNITE-22639
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We have different casts for literals and for dynamic parameters.
> For example, we have a table
> {code:java}
> CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
> For literals:
> {code:java}
> INSERT INTO T VALUES(100,100)
> --
> KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
> expressions=[[CAST(100):TINYINT NOT NULL, CAST(100):TINYINT NOT NULL]]){code}
> for dynamic parameters:
> {code:java}
> INSERT INTO T VALUES(?,?)
> --
> KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
> expressions=[[CAST(?0):TINYINT, ?1]]): {code}
> We should have the same types and casts for both cases.
> See
> org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest.
> During fix the issue let's also add additional test with dynamic parameters
> for all child of BaseTypeCoercionTest class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22655) Sql. incorrect error for quoted SQL
Iurii Gerzhedovich created IGNITE-22655:
---
Summary: Sql. incorrect error for quoted SQL
Key: IGNITE-22655
URL: https://issues.apache.org/jira/browse/IGNITE-22655
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Iurii Gerzhedovich
If a query is fully quoted it leads to an error message that the length must be
less than 128 characters.
Froexample:
{code:java}
"CREATE TABLE Trade (id long, buyer_id int, symbol varchar, order_quantity int,
bid_price double, trade_type varchar, order_date timestamp, PRIMARY KEY(id,
buyer_id)) COLOCATE BY buyer_id";{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22633) Catalog compaction. Choosing coordinator.
[ https://issues.apache.org/jira/browse/IGNITE-22633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22633: Issue Type: Improvement (was: Task) > Catalog compaction. Choosing coordinator. > - > > Key: IGNITE-22633 > URL: https://issues.apache.org/jira/browse/IGNITE-22633 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > By design, catalog compaction should only be performed by the coordinator > node. > Catalog compaction coordinator is the same node as the metastorage group > leader. > Basically, we need to implement logic (as part of the CatalogManager) that > will listen the metastorage leader election > (MetaStorageLeaderElectionListener?) and toggle an internal flag that will > indicate that the current node can initiate the catalog compaction procedure. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22639) Sql. Different casts for literals and for dynamic parameters
[
https://issues.apache.org/jira/browse/IGNITE-22639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22639:
Description:
We have different casts for literals and for dynamic parameters.
For example, we have a table
{code:java}
CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
For literals:
{code:java}
INSERT INTO T VALUES(100,100)
--
KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
expressions=[[CAST(100):TINYINT NOT NULL, CAST(100):TINYINT NOT NULL]]){code}
for dynamic parameters:
{code:java}
INSERT INTO T VALUES(?,?)
--
KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
expressions=[[CAST(?0):TINYINT, ?1]]): {code}
We must have the same
See
org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest.
During fix the issue let's also add additional test with dynamic parameters for
all child of BaseTypeCoercionTest class.
was:
We have different casts for literals and for dynamic parameters.
For example, we have a table
{code:java}
CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
For literals:
{code:java}
INSERT INTO T VALUES(100,100){code}
for dynamic parameters:
{code:java}
INSERT INTO T VALUES(?,?){code}
See
org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest
> Sql. Different casts for literals and for dynamic parameters
>
>
> Key: IGNITE-22639
> URL: https://issues.apache.org/jira/browse/IGNITE-22639
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We have different casts for literals and for dynamic parameters.
> For example, we have a table
> {code:java}
> CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
> For literals:
> {code:java}
> INSERT INTO T VALUES(100,100)
> --
> KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
> expressions=[[CAST(100):TINYINT NOT NULL, CAST(100):TINYINT NOT NULL]]){code}
> for dynamic parameters:
> {code:java}
> INSERT INTO T VALUES(?,?)
> --
> KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
> expressions=[[CAST(?0):TINYINT, ?1]]): {code}
> We must have the same
> See
> org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest.
> During fix the issue let's also add additional test with dynamic parameters
> for all child of BaseTypeCoercionTest class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22639) Sql. Different casts for literals and for dynamic parameters
[
https://issues.apache.org/jira/browse/IGNITE-22639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22639:
Description:
We have different casts for literals and for dynamic parameters.
For example, we have a table
{code:java}
CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
For literals:
{code:java}
INSERT INTO T VALUES(100,100)
--
KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
expressions=[[CAST(100):TINYINT NOT NULL, CAST(100):TINYINT NOT NULL]]){code}
for dynamic parameters:
{code:java}
INSERT INTO T VALUES(?,?)
--
KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
expressions=[[CAST(?0):TINYINT, ?1]]): {code}
We should have the same types and casts for both cases.
See
org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest.
During fix the issue let's also add additional test with dynamic parameters for
all child of BaseTypeCoercionTest class.
was:
We have different casts for literals and for dynamic parameters.
For example, we have a table
{code:java}
CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
For literals:
{code:java}
INSERT INTO T VALUES(100,100)
--
KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
expressions=[[CAST(100):TINYINT NOT NULL, CAST(100):TINYINT NOT NULL]]){code}
for dynamic parameters:
{code:java}
INSERT INTO T VALUES(?,?)
--
KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
expressions=[[CAST(?0):TINYINT, ?1]]): {code}
We must have the same
See
org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest.
During fix the issue let's also add additional test with dynamic parameters for
all child of BaseTypeCoercionTest class.
> Sql. Different casts for literals and for dynamic parameters
>
>
> Key: IGNITE-22639
> URL: https://issues.apache.org/jira/browse/IGNITE-22639
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We have different casts for literals and for dynamic parameters.
> For example, we have a table
> {code:java}
> CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
> For literals:
> {code:java}
> INSERT INTO T VALUES(100,100)
> --
> KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
> expressions=[[CAST(100):TINYINT NOT NULL, CAST(100):TINYINT NOT NULL]]){code}
> for dynamic parameters:
> {code:java}
> INSERT INTO T VALUES(?,?)
> --
> KeyValueModify(table=[[PUBLIC, T]], operation=[PUT],
> expressions=[[CAST(?0):TINYINT, ?1]]): {code}
> We should have the same types and casts for both cases.
> See
> org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest.
> During fix the issue let's also add additional test with dynamic parameters
> for all child of BaseTypeCoercionTest class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22639) Sql. Different casts for literals and for dynamic parameters
[
https://issues.apache.org/jira/browse/IGNITE-22639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22639:
Labels: ignite-3 (was: )
> Sql. Different casts for literals and for dynamic parameters
>
>
> Key: IGNITE-22639
> URL: https://issues.apache.org/jira/browse/IGNITE-22639
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We have different casts for literals and for dynamic parameters.
> For example, we have a table
> {code:java}
> CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
> For literals:
> {code:java}
> INSERT INTO T VALUES(100,100){code}
> for dynamic parameters:
> {code:java}
> INSERT INTO T VALUES(?,?){code}
>
> See
> org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22639) Sql. Different casts for literals and for dynamic parameters
Iurii Gerzhedovich created IGNITE-22639:
---
Summary: Sql. Different casts for literals and for dynamic
parameters
Key: IGNITE-22639
URL: https://issues.apache.org/jira/browse/IGNITE-22639
Project: Ignite
Issue Type: Improvement
Reporter: Iurii Gerzhedovich
We have different casts for literals and for dynamic parameters.
For example, we have a table
{code:java}
CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
For literals:
{code:java}
INSERT INTO T VALUES(100,100){code}
for dynamic parameters:
{code:java}
INSERT INTO T VALUES(?,?){code}
See
org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22639) Sql. Different casts for literals and for dynamic parameters
[
https://issues.apache.org/jira/browse/IGNITE-22639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22639:
Component/s: sql
> Sql. Different casts for literals and for dynamic parameters
>
>
> Key: IGNITE-22639
> URL: https://issues.apache.org/jira/browse/IGNITE-22639
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We have different casts for literals and for dynamic parameters.
> For example, we have a table
> {code:java}
> CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT){code}
> For literals:
> {code:java}
> INSERT INTO T VALUES(100,100){code}
> for dynamic parameters:
> {code:java}
> INSERT INTO T VALUES(?,?){code}
>
> See
> org.apache.ignite.internal.sql.engine.planner.datatypes.DmlSourcesCoercionTest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22635) Sql. Unable to optimize plan error for input out of range
Iurii Gerzhedovich created IGNITE-22635:
---
Summary: Sql. Unable to optimize plan error for input out of range
Key: IGNITE-22635
URL: https://issues.apache.org/jira/browse/IGNITE-22635
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Iurii Gerzhedovich
In some cases, we can't make a query plan in case input values is out of range
of destination.
For example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT)");
Double d = Double.MAX_VALUE;
igniteSql().execute(null, "INSERT INTO TEST VALUES (" + d + ", " + d + ")");
}{code}
—
{code:java}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:00bc7f29-ac6d-4ff0-a390-17d5414d600f Unable to optimize plan due to
internal error
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
at
org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:789)
at
org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:723)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:658)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
at
org.apache.ignite.internal.sql.api.IgniteSqlImpl.execute(IgniteSqlImpl.java:210)
at
org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.lambda$execute$1(PublicApiThreadingIgniteSql.java:65)
at
org.apache.ignite.internal.thread.PublicApiThreading.executeWithRole(PublicApiThreading.java:144)
at
org.apache.ignite.internal.thread.PublicApiThreading.execUserSyncOperation(PublicApiThreading.java:102)
at
org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.execute(PublicApiThreadingIgniteSql.java:65)
at
org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.t(ItSqlApiBaseTest.java:551)
at java.base/java.lang.reflect.Method.invoke(Method.java:580) at
java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at
java.base/java.util.ArrayList.forEach(ArrayList.java:1596)Caused by:
java.util.concurrent.CompletionException: org.apache.ignite.sql.SqlException:
IGN-CMN-65535 TraceId:00bc7f29-ac6d-4ff0-a390-17d5414d600f Unable to optimize
plan due to internal error at
org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$5(IgniteSqlImpl.java:379)
at
java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:990)
at
java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:974)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)Caused by:
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:00bc7f29-ac6d-4ff0-a390-17d5414d600f Unable to optimize plan due to
internal error at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:166)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.doOptimize(PrepareServiceImpl.java:578)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$7(PrepareServiceImpl.java:426)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
... 3 moreCaused by: java.lang.ArithmeticException: Value
1.7976931348623157E308 out of range at
org.apache.calcite.linq4j.tree.Primitive.checkRoundedRange(Primitive.java:383)
at
org.apache.calcite.linq4j.tree.Primitive.numberValue(Primitive.java:402) at
org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:575)at
org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
at
org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
at
org.apache.calcite.linq4j.tree.TernaryExpression.accept(TernaryExpression.java:47)
at
org.apache.calcite.linq4j.tree.Expressions.acceptExpressions(Expressions.java:3266)
at
org.apache.calcite.linq4j.tree.NewArrayExpression.accept(NewArrayExpression.java:49)
at org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:64)
at org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:455)
at org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:340)
at
[jira] [Assigned] (IGNITE-22448) Sql. Incorrect error message when aggregate function is called with UUID type
[
https://issues.apache.org/jira/browse/IGNITE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reassigned IGNITE-22448:
---
Assignee: Maksim Zhuravkov
> Sql. Incorrect error message when aggregate function is called with UUID type
> -
>
> Key: IGNITE-22448
> URL: https://issues.apache.org/jira/browse/IGNITE-22448
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> When the AVG function called with a DATE the validator returns the following
> error:
> {noformat}
> statement error: Cannot apply 'AVG' to arguments of type 'AVG()'.
> Supported form(s): 'AVG()'
> SELECT AVG('2011-01-01'::DATE)
> {noformat}
> But when AVG is called with UUID we get this:
> {noformat}
> statement error: Unable to optimize plan due to internal error
> SELECT AVG('c4a0327c-44be-416d-ae90-75c05079789f'::UUID)
> {noformat}
> As this query is transformed to
> {noformat}
> SELECT AVG('c4a0327c-44be-416d-ae90-75c05079789f' :: UUID)
> LogicalAggregate(group=[{}], EXPR$0=[AVG($0)]), id = 1048
> LogicalProject($f0=[CAST(_UTF-8'c4a0327c-44be-416d-ae90-75c05079789f'):UUID
> NOT NULL]), id = 1047
> LogicalValues(tuples=[[{ 0 }]]), id = 1044
> {noformat}
> Underlying cause:
> {noformat}
> java.lang.AssertionError: SUM is not supported for ANY
> at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators.unsupportedAggregateFunction(Accumulators.java:809)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators.sumFactory(Accumulators.java:138)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators.accumulatorFunctionFactory(Accumulators.java:83)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators.accumulatorFactory(Accumulators.java:66)
> at
> org.apache.ignite.internal.sql.engine.util.PlanUtils.addAccumulatorFields(PlanUtils.java:130)
> at
> org.apache.ignite.internal.sql.engine.util.PlanUtils.createHashAggRowType(PlanUtils.java:118)
> at
> org.apache.ignite.internal.sql.engine.rel.agg.IgniteMapHashAggregate.deriveRowType(IgniteMapHashAggregate.java:93)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:174)
> at
> org.apache.ignite.internal.sql.engine.rel.agg.MapReduceAggregates.buildAggregates(MapReduceAggregates.java:196)
> at
> org.apache.ignite.internal.sql.engine.rule.HashAggregateConverterRule$MapReduceHashAggregateConverterRule.convert(HashAggregateConverterRule.java:157)
> at
> org.apache.ignite.internal.sql.engine.rule.HashAggregateConverterRule$MapReduceHashAggregateConverterRule.convert(HashAggregateConverterRule.java:91)
> at
> org.apache.ignite.internal.sql.engine.rule.AbstractIgniteConverterRule.convert(AbstractIgniteConverterRule.java:51)
>
> {noformat}
> *Expected behaviour*
> It would be better to return a type error instead of an internal error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22587) Catalog compaction
[ https://issues.apache.org/jira/browse/IGNITE-22587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22587: Labels: ignite-3 (was: ) > Catalog compaction > -- > > Key: IGNITE-22587 > URL: https://issues.apache.org/jira/browse/IGNITE-22587 > Project: Ignite > Issue Type: Epic >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Catalog maintains a history of the evolution of its objects. The history may > grow over time, which leads to the occupation of a significant amount of > storage space to keep the update log, the occupation of a significant amount > of memory since every node in the cluster maintains its on-heap cache of > version snapshots, and increased time of node startup since every node should > restore version history and populate its on-heap cache. To address these > issues, catalog compaction was introduced. The problem is, at the moment the > compaction is not triggered at all, because truncation of the catalog's > history may affect other components. > The goal of the epic collect together tickets on implement the triggers of > the compaction -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22611) SQL. Statement should not extends AutoClosable
[ https://issues.apache.org/jira/browse/IGNITE-22611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22611: Component/s: sql > SQL. Statement should not extends AutoClosable > --- > > Key: IGNITE-22611 > URL: https://issues.apache.org/jira/browse/IGNITE-22611 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Statement doesn't hold any resources, but AutoClosable interface assume using > try-with-resources. > A try-with-resources block forces user to catch the exception, because of > `close()` method signature. > However, all of this make no sense, single implementation has empty `close()` > method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22611) SQL. Statement should not extends AutoClosable
[ https://issues.apache.org/jira/browse/IGNITE-22611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22611: Labels: ignite-3 (was: ) > SQL. Statement should not extends AutoClosable > --- > > Key: IGNITE-22611 > URL: https://issues.apache.org/jira/browse/IGNITE-22611 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Statement doesn't hold any resources, but AutoClosable interface assume using > try-with-resources. > A try-with-resources block forces user to catch the exception, because of > `close()` method signature. > However, all of this make no sense, single implementation has empty `close()` > method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22588) AI3 JDBC performance is low
[ https://issues.apache.org/jira/browse/IGNITE-22588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-22588: --- Assignee: Konstantin Orlov > AI3 JDBC performance is low > --- > > Key: IGNITE-22588 > URL: https://issues.apache.org/jira/browse/IGNITE-22588 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Despite resolving IGNITE-22413 we still have bad JDBC performance. > Let's investigate the reason and prepare plan to improve it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21956) SQL Features tests. Phase 2
[ https://issues.apache.org/jira/browse/IGNITE-21956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich resolved IGNITE-21956. - Resolution: Done > SQL Features tests. Phase 2 > --- > > Key: IGNITE-21956 > URL: https://issues.apache.org/jira/browse/IGNITE-21956 > Project: Ignite > Issue Type: Epic > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have a set of SQL features that have poor test coverage. > Let’s improve that. > List of features to improve test coverage: > |Feature type|Feature id|Feature Name|sub feature id|sub feature name| > |Mandatory|E021|Character string types|10|Implicit casting among the > character string types| > |Mandatory|E021|Character string types|11|POSITION function| > |Mandatory|E021|Character string types|12|Character comparison| > |Mandatory|E031|Identifiers|1|Delimited identifiers| > |Mandatory|E061|Basic predicates and search conditions|7|Quantified > comparison predicate| > |Mandatory|E071|Basic query expressions|2|UNION ALL table operator| > |Mandatory|E091|Set functions|1|AVG| > |Mandatory|E091|Set functions|6|ALL quantifier| > |Mandatory|E141|Basic integrity constraints|7|Column defaults| > |Mandatory|F031|Basic schema manipulation|4|ALTER TABLE statement: ADD COLUMN > clause| > |Mandatory|F051|Basic date and time|6|CURRENT_DATE| > |Mandatory|F051|Basic date and time|7|LOCALTIME| > |Mandatory|F051|Basic date and time|8|LOCALTIMESTAMP| > |Mandatory|F201|CAST function| | | > |Mandatory|F221|Explicit defaults| | | > |Optional|F302|INTERSECT table operator|1|INTERSECT DISTINCT table operator| > |Optional|F661|Simple tables| | | > |Optional|F781|Self-referencing operations| | | > |Optional|F861|Top-level in | | | > |Optional|F862| in subqueries| | | > |Optional|T021|BINARY and VARBINARY data types| | | > |Optional|T031|BOOLEAN data type| | | > |Optional|T621|Enhanced numeric functions| | | > |Optional|T624|Common logarithm functions| | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19997) Sql. Enhancing test coverage of type coercion
[ https://issues.apache.org/jira/browse/IGNITE-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-19997: Epic Link: (was: IGNITE-21956) > Sql. Enhancing test coverage of type coercion > - > > Key: IGNITE-19997 > URL: https://issues.apache.org/jira/browse/IGNITE-19997 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Currently, we have neither an understanding of how type coercion impacts the > system, nor decent test coverage. As a result, trying to fix one part causes > the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). > To improve the situation, let us perform the following steps: > * first, it is necessary to cover the current behavior of planner with an > exhaustive set of tests:. Here, we need to cover following cases > ** coercion for set operations like UNION, INTERSECT and EXCEPT > ** coercion for binary comparison and arithmetic > ** coercion for IN operator > ** coercion for CASE operator > ** coercion for function arguments > ** coercion of source for INSERT, UPDATE and MERGE operators > ** etc (did I miss something?) > * then, we need to cover execution by the similar tests to make sure > coercion and execution are aligned > * finally, we should revise coercion rules to remove unnecessary casts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19997) Sql. Enhancing test coverage of type coercion
[ https://issues.apache.org/jira/browse/IGNITE-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-19997: Description: Currently, we have neither an understanding of how type coercion impacts the system, nor decent test coverage. As a result, trying to fix one part causes the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). To improve the situation, let us perform the following steps: * first, it is necessary to cover the current behavior of planner with an exhaustive set of tests:. Here, we need to cover following cases ** coercion for set operations like UNION, INTERSECT and EXCEPT ** coercion for binary comparison and arithmetic ** coercion for IN operator ** coercion for CASE operator ** coercion for function arguments ** coercion of source for INSERT, UPDATE and MERGE operators ** etc (did I miss something?) * then, we need to cover execution by the similar tests to make sure coercion and execution are aligned * finally, we should revise coercion rules to remove unnecessary casts was: Currently, we have neither an understanding of how type coercion impacts the system, nor decent test coverage. As a result, trying to fix one part causes the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). To improve the situation, let us perform the following steps: * first, it is necessary to cover the current behavior of planner with an exhaustive set of tests:. Here, we need to cover following cases ** -coercion for set operations like UNION, INTERSECT and EXCEPT- ** -coercion for binary comparison and arithmetic- ** coercion for IN operator ** coercion for CASE operator ** coercion for function arguments ** coercion of source for INSERT, UPDATE and MERGE operators ** etc (did I miss something?) * then, we need to cover execution by the similar tests to make sure coercion and execution are aligned * finally, we should revise coercion rules to remove unnecessary casts > Sql. Enhancing test coverage of type coercion > - > > Key: IGNITE-19997 > URL: https://issues.apache.org/jira/browse/IGNITE-19997 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Currently, we have neither an understanding of how type coercion impacts the > system, nor decent test coverage. As a result, trying to fix one part causes > the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). > To improve the situation, let us perform the following steps: > * first, it is necessary to cover the current behavior of planner with an > exhaustive set of tests:. Here, we need to cover following cases > ** coercion for set operations like UNION, INTERSECT and EXCEPT > ** coercion for binary comparison and arithmetic > ** coercion for IN operator > ** coercion for CASE operator > ** coercion for function arguments > ** coercion of source for INSERT, UPDATE and MERGE operators > ** etc (did I miss something?) > * then, we need to cover execution by the similar tests to make sure > coercion and execution are aligned > * finally, we should revise coercion rules to remove unnecessary casts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22326) KeyValue/RecordView. Update marshaller code to restrict range of values legal for year field of LocalDate/LocalDateTime types
[ https://issues.apache.org/jira/browse/IGNITE-22326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich resolved IGNITE-22326. - Resolution: Won't Fix There are cases when restriction from SQL is not important and user can use just KV/RW > KeyValue/RecordView. Update marshaller code to restrict range of values legal > for year field of LocalDate/LocalDateTime types > - > > Key: IGNITE-22326 > URL: https://issues.apache.org/jira/browse/IGNITE-22326 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > KeyValue/RecordView handling of date type logic should be consistent with SQL > and allow only values legal for both APIs. > Let's update marshaller code to reject dates that can not be stored via SQL > API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22588) AI3 JDBC performance is low
Iurii Gerzhedovich created IGNITE-22588: --- Summary: AI3 JDBC performance is low Key: IGNITE-22588 URL: https://issues.apache.org/jira/browse/IGNITE-22588 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich Despite resolving IGNITE-22413 we still have bad JDBC performance. Let's investigate the reason and prepare plan to improve it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22587) Catalog compaction
Iurii Gerzhedovich created IGNITE-22587: --- Summary: Catalog compaction Key: IGNITE-22587 URL: https://issues.apache.org/jira/browse/IGNITE-22587 Project: Ignite Issue Type: Epic Reporter: Iurii Gerzhedovich Catalog maintains a history of the evolution of its objects. The history may grow over time, which leads to the occupation of a significant amount of storage space to keep the update log, the occupation of a significant amount of memory since every node in the cluster maintains its on-heap cache of version snapshots, and increased time of node startup since every node should restore version history and populate its on-heap cache. To address these issues, catalog compaction was introduced. The problem is, at the moment the compaction is not triggered at all, because truncation of the catalog's history may affect other components. The goal of the epic collect together tickets on implement the triggers of the compaction -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19162) Sql. Trim all less than millisecond information from timestamp.
[
https://issues.apache.org/jira/browse/IGNITE-19162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860120#comment-17860120
]
Iurii Gerzhedovich commented on IGNITE-19162:
-
It can't be fixed on the Ignite side, it should be fixed in Calcite
> Sql. Trim all less than millisecond information from timestamp.
> ---
>
> Key: IGNITE-19162
> URL: https://issues.apache.org/jira/browse/IGNITE-19162
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trim useful timestamp part:
> {noformat}
> CREATE TABLE timestamps(id INTEGER PRIMARY KEY, i TIMESTAMP(9));
> INSERT INTO timestamps VALUES (101, TIMESTAMP '2023-03-29 08:22:33.005007');
> SELECT i from timestamps; <--- expect inserted, obtain trimmed : 2023-03-29
> 08:22:33.005
> {noformat}
> The root cause :
> RelJson#toJson() -> getValue3 -> getValue2 ->
> RexLiteral#getValueAs ->
> case TIMESTAMP:
> if (clazz == Long.class) {
>
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
> <-- here info is loosed.
> }
> Also CURRENT_TIMESTAMP return only 3 digits after last dot, don`t take into
> account *TIMESTAMP(precision)*
> The same for default value :
> testInsertDefaultValue ->
> DdlSqlToCommandConverter#fromLiteral
> case TIMESTAMP:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22262) Sql. Fix SQL API usage example (SqlApiExample)
[
https://issues.apache.org/jira/browse/IGNITE-22262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860111#comment-17860111
]
Iurii Gerzhedovich commented on IGNITE-22262:
-
[~xtern] LGTM. Thanks!
> Sql. Fix SQL API usage example (SqlApiExample)
> --
>
> Key: IGNITE-22262
> URL: https://issues.apache.org/jira/browse/IGNITE-22262
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The SQL API usage example {{SqlApiExample}} is broken, we need to make it
> work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22406) Jdbc. Schema can't be set as parameter in URL
[ https://issues.apache.org/jira/browse/IGNITE-22406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich resolved IGNITE-22406. - Resolution: Not A Problem It was intentionally implemented so. We have a special part of the URL to set the schema name. > Jdbc. Schema can't be set as parameter in URL > - > > Key: IGNITE-22406 > URL: https://issues.apache.org/jira/browse/IGNITE-22406 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now schema can be set by two ways, through API (connection.setSchema) > and as separate part of URL just after host and port. However parameters also > can be passed as parameters and it doesn't work for schema. > jdbc:ignite:thin://host[:port][,host[:port][/SCHEMA][[?parameter1=value1][=value1],...]] > > Let's fix it. Seems need to add the parameter to > org.apache.ignite.internal.jdbc.ConnectionPropertiesImpl#propsArray -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22581) Sql. Add planner test to verify numeric type coercion of source for INSERT, UPDATE and MERGE operators
[ https://issues.apache.org/jira/browse/IGNITE-22581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22581: Description: Let's add new tests to validate type coercion of source for INSERT, UPDATE, MERGE operators. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?" (was: Let's add new tests to validate type coercion for IN operator. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?") > Sql. Add planner test to verify numeric type coercion of source for INSERT, > UPDATE and MERGE operators > -- > > Key: IGNITE-22581 > URL: https://issues.apache.org/jira/browse/IGNITE-22581 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion of source for INSERT, UPDATE, > MERGE operators. The tests should be as easy as possible, every test case > must answer a question "what are expected types of each set operation when we > use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22581) Sql. Add planner test to verify numeric type coercion of source for INSERT, UPDATE and MERGE operators
[ https://issues.apache.org/jira/browse/IGNITE-22581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22581: Summary: Sql. Add planner test to verify numeric type coercion of source for INSERT, UPDATE and MERGE operators (was: Sql. Add planner test to verify numeric type coercion for INSERT, UPDATE and MERGE operators) > Sql. Add planner test to verify numeric type coercion of source for INSERT, > UPDATE and MERGE operators > -- > > Key: IGNITE-22581 > URL: https://issues.apache.org/jira/browse/IGNITE-22581 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for IN operator. The tests > should be as easy as possible, every test case must answer a question "what > are expected types of each set operation when we use a given numeric type > pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22581) Sql. Add planner test to verify numeric type coercion for INSERT, UPDATE and MERGE operators
Iurii Gerzhedovich created IGNITE-22581: --- Summary: Sql. Add planner test to verify numeric type coercion for INSERT, UPDATE and MERGE operators Key: IGNITE-22581 URL: https://issues.apache.org/jira/browse/IGNITE-22581 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich Assignee: Iurii Gerzhedovich Let's add new tests to validate type coercion for IN operator. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22580) Sql. Add planner test to verify numeric type coercion for CASE operator
[ https://issues.apache.org/jira/browse/IGNITE-22580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22580: Description: Let's add new tests to validate type coercion for CASE operator. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?" (was: Let's add new tests to validate type coercion for IN operator. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?") > Sql. Add planner test to verify numeric type coercion for CASE operator > --- > > Key: IGNITE-22580 > URL: https://issues.apache.org/jira/browse/IGNITE-22580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for CASE operator. The tests > should be as easy as possible, every test case must answer a question "what > are expected types of each set operation when we use a given numeric type > pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22580) Sql. Add planner test to verify numeric type coercion for CASE operator
Iurii Gerzhedovich created IGNITE-22580: --- Summary: Sql. Add planner test to verify numeric type coercion for CASE operator Key: IGNITE-22580 URL: https://issues.apache.org/jira/browse/IGNITE-22580 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich Assignee: Iurii Gerzhedovich Let's add new tests to validate type coercion for IN operator. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22579) Sql. Add planner test to verify numeric type coercion for IN operator
[ https://issues.apache.org/jira/browse/IGNITE-22579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22579: Description: Let's add new tests to validate type coercion for IN operator. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?" (was: Let's add new tests to validate type coercion for set operations like UNION, INTERSECT and EXCEPT. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?") > Sql. Add planner test to verify numeric type coercion for IN operator > - > > Key: IGNITE-22579 > URL: https://issues.apache.org/jira/browse/IGNITE-22579 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for IN operator. The tests > should be as easy as possible, every test case must answer a question "what > are expected types of each set operation when we use a given numeric type > pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22579) Sql. Add planner test to verify numeric type coercion for IN operator
Iurii Gerzhedovich created IGNITE-22579: --- Summary: Sql. Add planner test to verify numeric type coercion for IN operator Key: IGNITE-22579 URL: https://issues.apache.org/jira/browse/IGNITE-22579 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich Assignee: Iurii Gerzhedovich Let's add new tests to validate type coercion for set operations like UNION, INTERSECT and EXCEPT. The tests should be as easy as possible, every test case must answer a question "what are expected types of each set operation when we use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19997) Sql. Enhancing test coverage of type coercion
[ https://issues.apache.org/jira/browse/IGNITE-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-19997: Description: Currently, we have neither an understanding of how type coercion impacts the system, nor decent test coverage. As a result, trying to fix one part causes the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). To improve the situation, let us perform the following steps: * first, it is necessary to cover the current behavior of planner with an exhaustive set of tests:. Here, we need to cover following cases ** -coercion for set operations like UNION, INTERSECT and EXCEPT- ** -coercion for binary comparison and arithmetic- ** coercion for IN operator ** coercion for CASE operator ** coercion for function arguments ** coercion of source for INSERT, UPDATE and MERGE operators ** etc (did I miss something?) * then, we need to cover execution by the similar tests to make sure coercion and execution are aligned * finally, we should revise coercion rules to remove unnecessary casts was: Currently, we have neither an understanding of how type coercion impacts the system, nor decent test coverage. As a result, trying to fix one part causes the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). To improve the situation, let us perform the following steps: * first, it is necessary to cover the current behavior of planner with an exhaustive set of tests:. Here, we need to cover following cases ** coercion for set operations like UNION, INTERSECT and EXCEPT ** coercion for binary comparison and arithmetic ** coercion for IN operator ** coercion for CASE operator ** coercion for function arguments ** coercion of source for INSERT, UPDATE and MERGE operators ** etc (did I miss something?) * then, we need to cover execution by the similar tests to make sure coercion and execution are aligned * finally, we should revise coercion rules to remove unnecessary casts > Sql. Enhancing test coverage of type coercion > - > > Key: IGNITE-19997 > URL: https://issues.apache.org/jira/browse/IGNITE-19997 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Currently, we have neither an understanding of how type coercion impacts the > system, nor decent test coverage. As a result, trying to fix one part causes > the other to break (see IGNITE-19128 --> IGNITE-19615 --> IGNITE-19976). > To improve the situation, let us perform the following steps: > * first, it is necessary to cover the current behavior of planner with an > exhaustive set of tests:. Here, we need to cover following cases > ** -coercion for set operations like UNION, INTERSECT and EXCEPT- > ** -coercion for binary comparison and arithmetic- > ** coercion for IN operator > ** coercion for CASE operator > ** coercion for function arguments > ** coercion of source for INSERT, UPDATE and MERGE operators > ** etc (did I miss something?) > * then, we need to cover execution by the similar tests to make sure > coercion and execution are aligned > * finally, we should revise coercion rules to remove unnecessary casts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22462) Sql. Add planner test to verify type coercion for set operations like UNION, INTERSECT and EXCEPT
[ https://issues.apache.org/jira/browse/IGNITE-22462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22462: Summary:Sql. Add planner test to verify type coercion for set operations like UNION, INTERSECT and EXCEPT (was: ю) > Sql. Add planner test to verify type coercion for set operations like > UNION, INTERSECT and EXCEPT > -- > > Key: IGNITE-22462 > URL: https://issues.apache.org/jira/browse/IGNITE-22462 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for set operations like UNION, > INTERSECT and EXCEPT. The tests should be as easy as possible, every test > case must answer a question "what are expected types of each set operation > when we use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22462) ю
[ https://issues.apache.org/jira/browse/IGNITE-22462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22462: Summary: ю (was: Sql. Add planner test to verify type coercion for set operations like UNION, INTERSECT and EXCEPT) > ю > - > > Key: IGNITE-22462 > URL: https://issues.apache.org/jira/browse/IGNITE-22462 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate type coercion for set operations like UNION, > INTERSECT and EXCEPT. The tests should be as easy as possible, every test > case must answer a question "what are expected types of each set operation > when we use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22421) Sql. Interval type. DDL statements should return a proper error
[
https://issues.apache.org/jira/browse/IGNITE-22421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich resolved IGNITE-22421.
-
Resolution: Fixed
[~mzhuravkov] Thanks for the contribution!
merged commit
[{{adf9194}}|https://github.com/apache/ignite-3/commit/adf91949fc10f11441f02bc9ac51cb27a0005c8c]
into main
> Sql. Interval type. DDL statements should return a proper error
> ---
>
> Key: IGNITE-22421
> URL: https://issues.apache.org/jira/browse/IGNITE-22421
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DDL statements that use INTERVAL type in column definitions return the
> following errors:
> *Current behaviour*
> {noformat}
> CREATE TABLE t (a INTERVAL MONTH, b INT, PRIMARY KEY(a))
> Err: Precision definition is necessary for column 'A' of type 'PERIOD'
> CREATE TABLE t (a INTERVAL SECOND, b INT, PRIMARY KEY(a))
> Err: Scale is not applicable for column 'A' of type 'DURATION'
> ALTER TABLE t ADD COLUMN c INTERVAL YEAR TO MONTH
> Precision definition is necessary for column 'C' of type 'PERIOD'
> {noformat}
> *Expected behaviour*
> Both statements should return an error that clearly indicates that INTERVAL
> types cannot be used in this context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22501) SQL. Batching DDL statement for scripts
Iurii Gerzhedovich created IGNITE-22501: --- Summary: SQL. Batching DDL statement for scripts Key: IGNITE-22501 URL: https://issues.apache.org/jira/browse/IGNITE-22501 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich >From an architectural perspective, AI3 has many waits for any DDL statements >due to need to have strong guarantees. It leads to a significant time of >execution initialization script of a database containing tens or tons of DDL ( >CREATE TABLE, CREATE INDEX ...) statements. To increase of performance such scripts we could do batch operations with a some reordering. We need to understand not all operations can be reordered. For example CREATE INDEX can't be executed earlier than CREATING TABLE, DROP TABLE can't be reordered with any other operation on the same table. As the first step, we can go with very simple optimization, but it should give as good boost for most cases. Let's batch all CREATE TABLE 's from a script while we meets only CREATE TABLE and CREATE INDEX statements and execute as first batch. The second batch will be CREATE INDEX statements which we meet during collecting the first batch. We can continuously repeat the operation as we start meet CREATE INDEX and CREATE TABLE statements. The proposed solution has one important consequences, which need to be reflected in the documentation. Operations can be reordered and any separated operations can be finished with an error, so after the user receives an error they can't be sure which part of the script was applied. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22462) Sql. Add planner test to verify type coercion for set operations like UNION, INTERSECT and EXCEPT
[ https://issues.apache.org/jira/browse/IGNITE-22462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-22462: --- Assignee: Iurii Gerzhedovich > Sql. Add planner test to verify type coercion for set operations like UNION, > INTERSECT and EXCEPT > - > > Key: IGNITE-22462 > URL: https://issues.apache.org/jira/browse/IGNITE-22462 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > > Let's add new tests to validate type coercion for set operations like UNION, > INTERSECT and EXCEPT. The tests should be as easy as possible, every test > case must answer a question "what are expected types of each set operation > when we use a given numeric type pair?" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22480) Sql. Optimize performance of multistatement with simple inserts
[ https://issues.apache.org/jira/browse/IGNITE-22480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22480: Description: Execution multistatement contains a big amount of INSERT statements take to much time. For example, world.sql from AI2 contains about 5k insert statements that took more than 2 minutes on my local machine. However, if the multistatement rewrite to a few inserts contains multi values (e.g. insert into t(a,b) values(1,2) values (2,3) values.) then it took just a few seconds. The fast check shows that most of the time consuptions by expression compilation. We have a few options for how it could be resolved: 1. Use expression interpretation for simple cases instead of compilation to java class. 2. Dynamically rewrite such inserts to prepared statements. 3. On AST level extract values (it will work just for literals) and create tuple for inserting by hands. Options ordered by the hardness of implementation. Let's start from 3rd, as the simplest to implement, and check how it will work. was: Execution multistatement contains a big amount of INSERT statements take to much time. For example, world.sql from AI2 contains about 5k insert statements that took more than 2 minutes on my local machine. However, if the multistatement rewrite to a few inserts contains multi values (e.g. insert into t(a,b) values(1,2) values (2,3) values.) then it took just a few seconds. The fast check shows that most of the time consuptions by expression compilation. We have a few options for how it could be resolved: 1. Use expression interpretation for simple cases instead of compilation to java class. 2. Dynamically rewrite such inserts to prepared statements. 3. On AST level extract values (it will work just for literals) and create tuple for inserting by hands. Options placed by the hardness of implementation. Let's start from 3rd, as the simplest to implement, and check how it will work. > Sql. Optimize performance of multistatement with simple inserts > --- > > Key: IGNITE-22480 > URL: https://issues.apache.org/jira/browse/IGNITE-22480 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > > Execution multistatement contains a big amount of INSERT statements take to > much time. For example, world.sql from AI2 contains about 5k insert > statements that took more than 2 minutes on my local machine. However, if the > multistatement rewrite to a few inserts contains multi values (e.g. insert > into t(a,b) values(1,2) values (2,3) values.) then it took just a few > seconds. > The fast check shows that most of the time consuptions by expression > compilation. > We have a few options for how it could be resolved: > 1. Use expression interpretation for simple cases instead of compilation to > java class. > 2. Dynamically rewrite such inserts to prepared statements. > 3. On AST level extract values (it will work just for literals) and create > tuple for inserting by hands. > Options ordered by the hardness of implementation. Let's start from 3rd, as > the simplest to implement, and check how it will work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22480) Sql. Optimize performance of multistatement with simple inserts
Iurii Gerzhedovich created IGNITE-22480: --- Summary: Sql. Optimize performance of multistatement with simple inserts Key: IGNITE-22480 URL: https://issues.apache.org/jira/browse/IGNITE-22480 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich Execution multistatement contains a big amount of INSERT statements take to much time. For example, world.sql from AI2 contains about 5k insert statements that took more than 2 minutes on my local machine. However, if the multistatement rewrite to a few inserts contains multi values (e.g. insert into t(a,b) values(1,2) values (2,3) values.) then it took just a few seconds. The fast check shows that most of the time consuptions by expression compilation. We have a few options for how it could be resolved: 1. Use expression interpretation for simple cases instead of compilation to java class. 2. Dynamically rewrite such inserts to prepared statements. 3. On AST level extract values (it will work just for literals) and create tuple for inserting by hands. Options placed by the hardness of implementation. Let's start from 3rd, as the simplest to implement, and check how it will work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22262) Startup instructions missing in SqlApiExample
[ https://issues.apache.org/jira/browse/IGNITE-22262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22262: Description: * Standard header with node start instructions is missing. * The example fails if you run it as is (without starting a properly configured node) was: * Standard header with node start instructions is missing. * The example fails if you run it as is (without starting a properly configured node) > Startup instructions missing in SqlApiExample > - > > Key: IGNITE-22262 > URL: https://issues.apache.org/jira/browse/IGNITE-22262 > Project: Ignite > Issue Type: Bug > Components: examples >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * Standard header with node start instructions is missing. > * The example fails if you run it as is (without starting a properly > configured node) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22466) Sql. Support mapping on backup replicas
[ https://issues.apache.org/jira/browse/IGNITE-22466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22466: Description: At the moment, mapping service support mapping only on primary replicas. To improve data colocation, we may use backup replicas as well for RO queries. Let's improve mapping service in order to take advantage of backups locality and minimize amount data sent over the network. Some failures that should be considered during implementation: * Replica is not ready yet * Replica has already gone * Replica may be too outdated (safeTime of the replica is far behind of safeTime of the primary) * Anything else? was: At the moment, mapping service support mapping only on primary replicas. To improve data colocation, we may use backup replicas as well for RO queries. Let's improve mapping service in order to take advantage of backups locality and minimize amount data sent over the network. Some failures that should be considered during implementation: * Replica is not ready yet * Replica has already gone * Replica may be too outdated (safeTime of the replica is far behind of safeTime of the primary) * Anything else? > Sql. Support mapping on backup replicas > --- > > Key: IGNITE-22466 > URL: https://issues.apache.org/jira/browse/IGNITE-22466 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, mapping service support mapping only on primary replicas. To > improve data colocation, we may use backup replicas as well for RO queries. > Let's improve mapping service in order to take advantage of backups locality > and minimize amount data sent over the network. > Some failures that should be considered during implementation: > * Replica is not ready yet > * Replica has already gone > * Replica may be too outdated (safeTime of the replica is far behind of > safeTime of the primary) > * Anything else? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22466) Sql. Support mapping on backup replicas
[ https://issues.apache.org/jira/browse/IGNITE-22466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-22466: Epic Link: IGNITE-22468 > Sql. Support mapping on backup replicas > --- > > Key: IGNITE-22466 > URL: https://issues.apache.org/jira/browse/IGNITE-22466 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, mapping service support mapping only on primary replicas. To > improve data colocation, we may use backup replicas as well for RO queries. > Let's improve mapping service in order to take advantage of backups locality > and minimize amount data sent over the network. > Some failures that should be considered during implementation: > * Replica is not ready yet > * Replica has already gone > * Replica may be too outdated (safeTime of the replica is far behind of > safeTime of the primary) > * Anything else? -- This message was sent by Atlassian Jira (v8.20.10#820010)
