[jira] [Assigned] (IGNITE-23359) Sql. Additional tests for "out of range" arithmetic operations
[ https://issues.apache.org/jira/browse/IGNITE-23359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-23359: --- Assignee: Evgeny Stanilovsky > Sql. Additional tests for "out of range" arithmetic operations > -- > > Key: IGNITE-23359 > URL: https://issues.apache.org/jira/browse/IGNITE-23359 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Required additional expanded tests for arithmetic operations which result > type is greater than operand type. > Need to be covered: > 1. literals > 2. dynamic parameters > 3. inserts from one column type to another -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23359) Sql. Additional tests for "out of range" arithmetic operations
[ https://issues.apache.org/jira/browse/IGNITE-23359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-23359: Description: Required additional expanded tests for arithmetic operations which result type is greater than operand type. Need to be covered: 1. literals 2. dynamic parameters 3. inserts from one column type to another > Sql. Additional tests for "out of range" arithmetic operations > -- > > Key: IGNITE-23359 > URL: https://issues.apache.org/jira/browse/IGNITE-23359 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Required additional expanded tests for arithmetic operations which result > type is greater than operand type. > Need to be covered: > 1. literals > 2. dynamic parameters > 3. inserts from one column type to another -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23359) Sql. Additional tests for "out of range" arithmetic operations
Evgeny Stanilovsky created IGNITE-23359: --- Summary: Sql. Additional tests for "out of range" arithmetic operations Key: IGNITE-23359 URL: https://issues.apache.org/jira/browse/IGNITE-23359 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23192) Sql. Arithmetic operations failed with "out of range" exception.
[
https://issues.apache.org/jira/browse/IGNITE-23192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886724#comment-17886724
]
Evgeny Stanilovsky commented on IGNITE-23192:
-
Seems this is correct behavior, cast for correct type need to be called for
overflow prevention.
> Sql. Arithmetic operations failed with "out of range" exception.
>
>
> Key: IGNITE-23192
> URL: https://issues.apache.org/jira/browse/IGNITE-23192
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> {noformat}
> sql("CREATE TABLE t(key int primary key, c1 tinyint, c2 tinyint)");
> sql("INSERT INTO t VALUES(1, 100, 100)");
> sql("SELECT c1 + c2 from t");
> // the same:
> sql("SELECT c1 * c2 from t");
> // will fail but need different insertion: INSERT INTO t VALUES(1, -100, 100)
> sql("SELECT c1 - c2 from t");
> {noformat}
> Failed with :
> "TINYINT out of range" exception, seems the same for int16 and int 32 types
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-23232) Sql. Different forms of notation for CAST operator return different results for same operands.
[
https://issues.apache.org/jira/browse/IGNITE-23232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky resolved IGNITE-23232.
-
Resolution: Invalid
> Sql. Different forms of notation for CAST operator return different results
> for same operands.
> --
>
> Key: IGNITE-23232
> URL: https://issues.apache.org/jira/browse/IGNITE-23232
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Expected that:
> {code:java}
> SELECT -9223372036854775808::BIGINT/-1::BIGINT
> {code}
> and
> {code:java}
> SELECT CAST (-9223372036854775808 as BIGINT)/-1::BIGINT
> {code}
> returns the same results, but it not true, check issue related code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23349) Sql. Investigate modulo reaction with different fractional types
Evgeny Stanilovsky created IGNITE-23349:
---
Summary: Sql. Investigate modulo reaction with different
fractional types
Key: IGNITE-23349
URL: https://issues.apache.org/jira/browse/IGNITE-23349
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Passed:
{noformat}
select '12'::int8 % '-2.2247526E4'::real
{noformat}
Failed:
{noformat}
select '12'::int8 % '-2.2247526E8'::real
{noformat}
{noformat}
Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-7
TraceId:24a5acaa-18de-4009-96de-4b5bfa4a1840 Numeric field overflow. A field
with precision 14, scale 7 must round to an absolute value less than 10^7.
at SC.execute(Unknown Source)
at
org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:772)
at
org.apache.ignite.internal.sql.engine.exec.rel.ProjectNode.push(ProjectNode.java:69)
at
org.apache.ignite.internal.sql.engine.exec.rel.ScanNode.push(ScanNode.java:125)
... 5 more
Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-7
TraceId:24a5acaa-18de-4009-96de-4b5bfa4a1840 Numeric field overflow. A field
with precision 14, scale 7 must round to an absolute value less than 10^7.
at
org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.numericOverflowError(IgniteSqlFunctions.java:433)
at
org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.processValueWithIntegralPart(IgniteSqlFunctions.java:377)
at
org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal(IgniteSqlFunctions.java:355)
at
org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal(IgniteSqlFunctions.java:276)
... 9 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23336) Append additional planner tests for arithmetic results type coercion
Evgeny Stanilovsky created IGNITE-23336: --- Summary: Append additional planner tests for arithmetic results type coercion Key: IGNITE-23336 URL: https://issues.apache.org/jira/browse/IGNITE-23336 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Append additional planner tests for arthmetic operations type coercion, seems it`s already done here [1] but instead of call for type derivation, type need to be statically defined in test. [1] https://github.com/apache/ignite-3/pull/4422/files#diff-8b1bae5c9289b608456ce36779acfbfa0e660e4e9f1e9cc7ddfb95c93c48d2e7R134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22663) Assertion error on kill transaction command
[
https://issues.apache.org/jira/browse/IGNITE-22663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884883#comment-17884883
]
Evgeny Stanilovsky commented on IGNITE-22663:
-
[~julia_bakulina] very strange version )
> Assertion error on kill transaction command
> ---
>
> Key: IGNITE-22663
> URL: https://issues.apache.org/jira/browse/IGNITE-22663
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Julia Bakulina
>Priority: Critical
> Labels: ise
> Attachments: logs.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Steps before:
> 1. Start a few transactions.
> 2. control.sh --tx --limit 2 --info
> 3. control.sh --tx --limit 2 --kill
> Cache cfg:
> {code:java}
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName("transactionsCache").setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL).setStatisticsEnabled(true);
> {code}
> Error:
> {code:java}
> 2024-07-04 17:16:26.757 [ERROR][sys-stripe-4-#5][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a
> transaction has produced runtime exception]]
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
> Committing a transaction has produced runtime exception
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:789)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:896)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:786)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:570)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:453)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:498)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitAsync(GridDhtTxLocal.java:513)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:791)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:118)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:542)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:350)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:339)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1368)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:724)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1130)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:390)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:612)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:409)
> ~[ignite-core-2.16.0.jar:2.16.0]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:197)
> ~[ignite-core-2.16.0.jar
[jira] [Created] (IGNITE-23232) Sql. Different forms of notation for CAST operator return different results for same operands.
Evgeny Stanilovsky created IGNITE-23232:
---
Summary: Sql. Different forms of notation for CAST operator return
different results for same operands.
Key: IGNITE-23232
URL: https://issues.apache.org/jira/browse/IGNITE-23232
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Expected that:
{code:java}
SELECT -9223372036854775808::BIGINT/-1::BIGINT
{code}
and
{code:java}
SELECT CAST (-9223372036854775808 as BIGINT)/-1::BIGINT
{code}
returns the same results, but it not true, check issue related code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23192) Sql. Arithmetic operations failed with "out of range" exception.
[
https://issues.apache.org/jira/browse/IGNITE-23192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-23192:
---
Assignee: Evgeny Stanilovsky
> Sql. Arithmetic operations failed with "out of range" exception.
>
>
> Key: IGNITE-23192
> URL: https://issues.apache.org/jira/browse/IGNITE-23192
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> sql("CREATE TABLE t(key int primary key, c1 tinyint, c2 tinyint)");
> sql("INSERT INTO t VALUES(1, 100, 100)");
> sql("SELECT c1 + c2 from t");
> // the same:
> sql("SELECT c1 * c2 from t");
> // will fail but need different insertion: INSERT INTO t VALUES(1, -100, 100)
> sql("SELECT c1 - c2 from t");
> {noformat}
> Failed with :
> "TINYINT out of range" exception, seems the same for int16 and int 32 types
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23201) Sql. Fix workaround for "rexList" serialization
[ https://issues.apache.org/jira/browse/IGNITE-23201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881533#comment-17881533 ] Evgeny Stanilovsky commented on IGNITE-23201: - [~jooger] can you make a review plz ? > Sql. Fix workaround for "rexList" serialization > --- > > Key: IGNITE-23201 > URL: https://issues.apache.org/jira/browse/IGNITE-23201 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Some workaround for "rexList" serialization was introduced during calcite > 1.37 upgrade, it need to be reworked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22360) Sql. SUBSTRING function should correctly process fractional values in its numeric arguments.
[
https://issues.apache.org/jira/browse/IGNITE-22360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22360:
Description:
The following queries should be rejected by the validator, because numeric
arguments other than INTs do not make any sense for this function:
{noformat}
SELECT SUBSTRING('aaa', 1.0);
SELECT SUBSTRING('aaa', 1.0, 2.3)
{noformat}
For now there is no implementation for SUBSTRING function which support
fractional types as arguments and as a result it will fail with runtime
exception, seems it need to be fixed and work with such operands too.
was:
The following queries should be rejected by the validator, because numeric
arguments other than INTs do not make any sense for this function:
{noformat}
SELECT SUBSTRING('aaa', 1.0);
SELECT SUBSTRING('aaa', 1.0, 2.3)
{noformat}
> Sql. SUBSTRING function should correctly process fractional values in its
> numeric arguments.
>
>
> Key: IGNITE-22360
> URL: https://issues.apache.org/jira/browse/IGNITE-22360
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> The following queries should be rejected by the validator, because numeric
> arguments other than INTs do not make any sense for this function:
> {noformat}
> SELECT SUBSTRING('aaa', 1.0);
> SELECT SUBSTRING('aaa', 1.0, 2.3)
> {noformat}
> For now there is no implementation for SUBSTRING function which support
> fractional types as arguments and as a result it will fail with runtime
> exception, seems it need to be fixed and work with such operands too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22360) Sql. SUBSTRING function should correctly process fractional values in its numeric arguments.
[
https://issues.apache.org/jira/browse/IGNITE-22360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22360:
Summary: Sql. SUBSTRING function should correctly process fractional values
in its numeric arguments. (was: Sql. SUBSTRING function should not accept
REAL/DOUBLE values in its numeric arguments.)
> Sql. SUBSTRING function should correctly process fractional values in its
> numeric arguments.
>
>
> Key: IGNITE-22360
> URL: https://issues.apache.org/jira/browse/IGNITE-22360
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> The following queries should be rejected by the validator, because numeric
> arguments other than INTs do not make any sense for this function:
> {noformat}
> SELECT SUBSTRING('aaa', 1.0);
> SELECT SUBSTRING('aaa', 1.0, 2.3)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23203) Write retry pages by multiple threads at checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-23203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881491#comment-17881491 ] Evgeny Stanilovsky commented on IGNITE-23203: - but as i remember a count of such a pages is not very big ... > Write retry pages by multiple threads at checkpoint > --- > > Key: IGNITE-23203 > URL: https://issues.apache.org/jira/browse/IGNITE-23203 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > I found that in > *org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointPagesWriter* > we write the retry pages with one thread (which filled them), which may be a > bit inefficient. > We can write these pages in parallel with several threads, for example, put > them in some concurrent queue in pairs List> and each thread would write the pages in parallel. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23201) Sql. Fix workaround for "rexList" serialization
[ https://issues.apache.org/jira/browse/IGNITE-23201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-23201: --- Assignee: Evgeny Stanilovsky > Sql. Fix workaround for "rexList" serialization > --- > > Key: IGNITE-23201 > URL: https://issues.apache.org/jira/browse/IGNITE-23201 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Some workaround for "rexList" serialization was introduced during calcite > 1.37 upgrade, it need to be reworked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23201) Sql. Fix workaround for "rexList" serialization
Evgeny Stanilovsky created IGNITE-23201: --- Summary: Sql. Fix workaround for "rexList" serialization Key: IGNITE-23201 URL: https://issues.apache.org/jira/browse/IGNITE-23201 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Some workaround for "rexList" serialization was introduced during calcite 1.37 upgrade, it need to be reworked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23141) Sql. Add execution test to verify numeric type coercion in binary comparison and arithmetic
[ https://issues.apache.org/jira/browse/IGNITE-23141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881262#comment-17881262 ] Evgeny Stanilovsky commented on IGNITE-23141: - [~korlov][~jooger] guys can you make a review plz ? > Sql. Add execution test to verify numeric type coercion in binary comparison > and arithmetic > --- > > Key: IGNITE-23141 > URL: https://issues.apache.org/jira/browse/IGNITE-23141 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We already have coercion planner test for binary comparison and arithmetic. > Let's add tests for the same operations but for execution and check have we > the same casts or not. > See NumericComparisonTypeCoercionTest and > NumericBinaryOperationsTypeCoercionTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-23141) Sql. Add execution test to verify numeric type coercion in binary comparison and arithmetic
[ https://issues.apache.org/jira/browse/IGNITE-23141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881262#comment-17881262 ] Evgeny Stanilovsky edited comment on IGNITE-23141 at 9/12/24 10:20 AM: --- [~korlov], [~jooger] guys can you make a review plz ? was (Author: zstan): [~korlov][~jooger] guys can you make a review plz ? > Sql. Add execution test to verify numeric type coercion in binary comparison > and arithmetic > --- > > Key: IGNITE-23141 > URL: https://issues.apache.org/jira/browse/IGNITE-23141 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We already have coercion planner test for binary comparison and arithmetic. > Let's add tests for the same operations but for execution and check have we > the same casts or not. > See NumericComparisonTypeCoercionTest and > NumericBinaryOperationsTypeCoercionTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23192) Sql. Arithmetic operations failed with "out of range" exception.
[
https://issues.apache.org/jira/browse/IGNITE-23192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-23192:
Description:
{noformat}
sql("CREATE TABLE t(key int primary key, c1 tinyint, c2 tinyint)");
sql("INSERT INTO t VALUES(1, 100, 100)");
sql("SELECT c1 + c2 from t");
// the same:
sql("SELECT c1 * c2 from t");
// will fail but need different insertion: INSERT INTO t VALUES(1, -100, 100)
sql("SELECT c1 - c2 from t");
{noformat}
Failed with :
"TINYINT out of range" exception, seems the same for int16 and int 32 types
was:
{noformat}
sql("CREATE TABLE t(key int primary key, c1 tinyint, c2 tinyint)");
sql("INSERT INTO t VALUES(1, 100, 100)");
sql("SELECT c1 + c2 from t");
{noformat}
Failed with :
"TINYINT out of range" exception, seems the same for int16 and int 32 types
> Sql. Arithmetic operations failed with "out of range" exception.
>
>
> Key: IGNITE-23192
> URL: https://issues.apache.org/jira/browse/IGNITE-23192
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> sql("CREATE TABLE t(key int primary key, c1 tinyint, c2 tinyint)");
> sql("INSERT INTO t VALUES(1, 100, 100)");
> sql("SELECT c1 + c2 from t");
> // the same:
> sql("SELECT c1 * c2 from t");
> // will fail but need different insertion: INSERT INTO t VALUES(1, -100, 100)
> sql("SELECT c1 - c2 from t");
> {noformat}
> Failed with :
> "TINYINT out of range" exception, seems the same for int16 and int 32 types
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23192) Sql. Arithmetic operations failed with "out of range" exception.
Evgeny Stanilovsky created IGNITE-23192:
---
Summary: Sql. Arithmetic operations failed with "out of range"
exception.
Key: IGNITE-23192
URL: https://issues.apache.org/jira/browse/IGNITE-23192
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
{noformat}
sql("CREATE TABLE t(key int primary key, c1 tinyint, c2 tinyint)");
sql("INSERT INTO t VALUES(1, 100, 100)");
sql("SELECT c1 + c2 from t");
{noformat}
Failed with :
"TINYINT out of range" exception, seems the same for int16 and int 32 types
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23141) Sql. Add execution test to verify numeric type coercion in binary comparison and arithmetic
[ https://issues.apache.org/jira/browse/IGNITE-23141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-23141: Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Add execution test to verify numeric type coercion in binary comparison > and arithmetic > --- > > Key: IGNITE-23141 > URL: https://issues.apache.org/jira/browse/IGNITE-23141 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We already have coercion planner test for binary comparison and arithmetic. > Let's add tests for the same operations but for execution and check have we > the same casts or not. > See NumericComparisonTypeCoercionTest and > NumericBinaryOperationsTypeCoercionTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23139) Sql. Fix failed "test_long_identifiers" test
[
https://issues.apache.org/jira/browse/IGNITE-23139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879794#comment-17879794
]
Evgeny Stanilovsky commented on IGNITE-23139:
-
[~amashenkov] plz make a review.
> Sql. Fix failed "test_long_identifiers" test
>
>
> Key: IGNITE-23139
> URL: https://issues.apache.org/jira/browse/IGNITE-23139
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Konstantin Orlov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {{org.apache.ignite.internal.sql.sqllogic.ItSqlLogicTest.sql(identifiers/test_long_identifiers.test)}}
> has failed on TC with:
> {code}
> java.lang.AssertionError: Not expected result at:
> (test_long_identifiers.test:151). [row=0, col=0, expected=1, actual=2]
> at org.apache.ignite.internal.sql.sqllogic.Query.checkEquals(Query.java:365)
> at
> org.apache.ignite.internal.sql.sqllogic.Query.checkResultTuples(Query.java:330)
> at org.apache.ignite.internal.sql.sqllogic.Query.checkResult(Query.java:306)
> at org.apache.ignite.internal.sql.sqllogic.Query.execute(Query.java:269)
> at
> org.apache.ignite.internal.sql.sqllogic.SqlScriptRunner.run(SqlScriptRunner.java:70)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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)
> {code}
> Let's investigate and fix the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22360) Sql. SUBSTRING function should not accept REAL/DOUBLE values in its numeric arguments.
[
https://issues.apache.org/jira/browse/IGNITE-22360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878866#comment-17878866
]
Evgeny Stanilovsky commented on IGNITE-22360:
-
fixed in : IGNITE-21243 Bump calcite version to 1.37
> Sql. SUBSTRING function should not accept REAL/DOUBLE values in its numeric
> arguments.
> --
>
> Key: IGNITE-22360
> URL: https://issues.apache.org/jira/browse/IGNITE-22360
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> The following queries should be rejected by the validator, because numeric
> arguments other than INTs do not make any sense for this function:
> {noformat}
> SELECT SUBSTRING('aaa', 1.0);
> SELECT SUBSTRING('aaa', 1.0, 2.3)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19882) Sql. Queries that access columns of type DECIMAL do not pick index, when compared with INT/BIGINT.
[
https://issues.apache.org/jira/browse/IGNITE-19882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-19882:
---
Assignee: Evgeny Stanilovsky
> Sql. Queries that access columns of type DECIMAL do not pick index, when
> compared with INT/BIGINT.
> --
>
> Key: IGNITE-19882
> URL: https://issues.apache.org/jira/browse/IGNITE-19882
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: ignite-3
>
> When decimal column is compared with literal/dynamic parameter of integral
> numeric type, index is not picked:
> {code:java}
> sql("CREATE TABLE t_dec (ID INTEGER PRIMARY KEY, VAL DECIMAL(5,3))");
> sql("CREATE INDEX t_dec_idx ON t_dec(VAL)");
> sql("INSERT INTO t_dec VALUES (1, 42)");
> // 1 passes
> assertQuery("SELECT id FROM t_dec WHERE val = 42.000")
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> // 2 passes
> assertQuery("SELECT id FROM t_dec WHERE val = 42::DECIMAL(5,3)")
>.matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
>.returns(1)
>.check();
> // 3 fails
> assertQuery("SELECT id FROM t_dec WHERE val = 42")
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> // 4 fails
> assertQuery("SELECT id FROM t_dec WHERE val = ?")
> .withParams(42)
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> // 5 fails
> assertQuery("SELECT id FROM t_dec WHERE val = ?")
> .withParams(42L)
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> {code}
> Expected behaviour: Queries 3, 4, 5 should use an index.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18644) Sql. Type system. Types in predicate expressions may have unnecessary casts.
[
https://issues.apache.org/jira/browse/IGNITE-18644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878496#comment-17878496
]
Evgeny Stanilovsky commented on IGNITE-18644:
-
now it throws correct equal exceptions for both cases, seems we can close it
> Sql. Type system. Types in predicate expressions may have unnecessary casts.
>
>
> Key: IGNITE-18644
> URL: https://issues.apache.org/jira/browse/IGNITE-18644
> 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
>
>
> Types in predicate expressions may have unnecessary casts that makes a result
> of a query execution dependent on data that resides in a table. Observed for
> IN operator and OR expressions b/c IN operator is rewritten as X in (a, b) is
> rewritten into X = a OR X = b.
> Table:
> {code:java}
> CREATE TABLE t1 (ID INTEGER PRIMARY KEY, c1 INTEGER);
> {code}
> Query:
> {code:java}
> SELECT c1 FROM t1 WHERE c1 IN (1, 2, 'b') {code}
> Execution of the following query depends on data that is stored in a table:
> - if c1 is 1 or 2 the following query does not raise an error.
> - If c2 is neither of those the query fails at runtime with Integer parse
> error.
> it would be better to have consistent behaviour (this requires removing the
> rendudant casts in predicate expressions).
> Reproducer:
> {code:java}
> sql("CREATE TABLE T11 (c1 int primary key, c2 INTEGER)");
> Transaction tx = CLUSTER_NODES.get(0).transactions().begin();
> sql(tx, "INSERT INTO T11 VALUES(1, 2)");
> sql(tx, "INSERT INTO T11 VALUES(2, 3)");
> tx.commit();
> // ok
> assertQuery("SELECT T11.c2 FROM T11 WHERE c2 IN (2, 'b')").check();
> // ok
> assertQuery("SELECT T11.c2 FROM T11 WHERE c2 IN (3, 'b')").check();
> // fails with java.lang.NumberFormatException: For input string: "b"
> assertQuery("SELECT T11.c2 FROM T11 WHERE c2 IN (4, 'b')").check(); {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23088) Sql. Serialization/deserialization of some numbers can be incorrect.
[
https://issues.apache.org/jira/browse/IGNITE-23088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-23088:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Serialization/deserialization of some numbers can be incorrect.
>
>
> Key: IGNITE-23088
> URL: https://issues.apache.org/jira/browse/IGNITE-23088
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> For some reason, a set of numbers can be serialized/deserialized in the right
> manner.
> Example:
> {code:java}
> SELECT CASE WHEN RAND_UUID() != RAND_UUID() THEN 9223372036854768299 ELSE
> 3.4028235E38 END FROM t
> org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
> Expected:
> rel#1323:TableScan.(table=[PUBLIC, T],projects=[CASE(<>(RAND_UUID(),
> RAND_UUID()), 9223372036854768299:DOUBLE,
> 3.4028235E38:DOUBLE)],requiredColumns={},sourceId=1)
> Deserialized:
> rel#1324:TableScan.(table=[PUBLIC, T],projects=[CASE(<>(RAND_UUID(),
> RAND_UUID()), 9.223372036854769E18:DOUBLE,
> 3.4028235E38:DOUBLE)],requiredColumns={},sourceId=1){code}
> Seems we ignore `typeName` for exact literals. Don't serialize and don't use
> the information during create a literal.
> A few places for start investigation:
> 1.
> org.apache.ignite.internal.sql.engine.externalize.RelJson#toJson(org.apache.calcite.rex.RexNode)
>
> case LITERAL:
> 2. org.apache.ignite.internal.sql.engine.externalize.RelJson#toRex
> if (map.containsKey("literal")) {
> 3. Test NumericCaseTypeCoercionTest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23088) Sql. Serialization/deserialization of some numbers can be incorrect.
[
https://issues.apache.org/jira/browse/IGNITE-23088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-23088:
---
Assignee: Evgeny Stanilovsky
> Sql. Serialization/deserialization of some numbers can be incorrect.
>
>
> Key: IGNITE-23088
> URL: https://issues.apache.org/jira/browse/IGNITE-23088
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> For some reason, a set of numbers can be serialized/deserialized in the right
> manner.
> Example:
> {code:java}
> SELECT CASE WHEN RAND_UUID() != RAND_UUID() THEN 9223372036854768299 ELSE
> 3.4028235E38 END FROM t
> org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
> Expected:
> rel#1323:TableScan.(table=[PUBLIC, T],projects=[CASE(<>(RAND_UUID(),
> RAND_UUID()), 9223372036854768299:DOUBLE,
> 3.4028235E38:DOUBLE)],requiredColumns={},sourceId=1)
> Deserialized:
> rel#1324:TableScan.(table=[PUBLIC, T],projects=[CASE(<>(RAND_UUID(),
> RAND_UUID()), 9.223372036854769E18:DOUBLE,
> 3.4028235E38:DOUBLE)],requiredColumns={},sourceId=1){code}
> Seems we ignore `typeName` for exact literals. Don't serialize and don't use
> the information during create a literal.
> A few places for start investigation:
> 1.
> org.apache.ignite.internal.sql.engine.externalize.RelJson#toJson(org.apache.calcite.rex.RexNode)
>
> case LITERAL:
> 2. org.apache.ignite.internal.sql.engine.externalize.RelJson#toRex
> if (map.containsKey("literal")) {
> 3. Test NumericCaseTypeCoercionTest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (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
]
Evgeny Stanilovsky reassigned IGNITE-20889:
---
Assignee: Evgeny Stanilovsky
> 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
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-23083) Sql. Avoid planner cache pollution with simple insert queries.
[ https://issues.apache.org/jira/browse/IGNITE-23083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-23083: Description: Simple insert queries like (INSERT INTO t VALUES (...)) should not be cached in planner cache. > Sql. Avoid planner cache pollution with simple insert queries. > -- > > Key: IGNITE-23083 > URL: https://issues.apache.org/jira/browse/IGNITE-23083 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Simple insert queries like (INSERT INTO t VALUES (...)) should not be cached > in planner cache. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23083) Sql. Avoid planner cache pollution with simple insert queries.
Evgeny Stanilovsky created IGNITE-23083: --- Summary: Sql. Avoid planner cache pollution with simple insert queries. Key: IGNITE-23083 URL: https://issues.apache.org/jira/browse/IGNITE-23083 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Assignee: Evgeny Stanilovsky -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23049) Benchmark HybridClock
[
https://issues.apache.org/jira/browse/IGNITE-23049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875804#comment-17875804
]
Evgeny Stanilovsky commented on IGNITE-23049:
-
results can be OS dependent, i hope.
> Benchmark HybridClock
> -
>
> Key: IGNITE-23049
> URL: https://issues.apache.org/jira/browse/IGNITE-23049
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Originally HybridClockImpl used
> {code:java}
> systemUTC().instant().toEpochMilli(){code}
> within Reduce latency for txn preparing phase it was substituted with
> {code:java}
> FastTimestamps.coarseCurrentTimeMillis(){code}
> that likely led to decreased test stability:
> #
> [ClockWaiterTest.futureCompletesWithoutClockUpdatesfailure|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8409117?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildDeploymentsSection=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true]
> #
> [IndexMetaStorageRecoveryTest.testMissingDropTable|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8411374?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&expandBuildTestsSection=true]
> #
> [ItIgniteDistributionZoneManagerNodeRestartTest.testScaleDownTimerIsRestoredAfterRestart(defaultZone=true)|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8414582?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandBuildDeploymentsSection=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true]
> Thus, it seems reasonable to benchmark following basis for HybridClock in
> order to choose the fastest and most reliable
> * systemUTC().instant().toEpochMilli()
> * System.currentTimeMillis()
> * FastTimestamps.coarseCurrentTimeMillis()
> h3. Defition of Done
> * Write benchmarks and compare results.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22785) Sql. Partition pruning. Insert. ArrayIndexOutOfBoundsException when key column literal overflows
[
https://issues.apache.org/jira/browse/IGNITE-22785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22785:
---
Assignee: Konstantin Orlov (was: Evgeny Stanilovsky)
> Sql. Partition pruning. Insert. ArrayIndexOutOfBoundsException when key
> column literal overflows
>
>
> Key: IGNITE-22785
> URL: https://issues.apache.org/jira/browse/IGNITE-22785
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Reproducer:
> 1. Disable KeyValueModifyPlan.
> 2. Run the following test case:
> {noformat}
> @Test
> public void dmlOps() {
> sql("CREATE TABLE test (id INT PRIMARY KEY, val INT);");
> sql(String.format("INSERT INTO test VALUES(%d, 1)", Long.MAX_VALUE));
> }
> {noformat}
> *Expected error*: SMALLINT out of range
> *Actual error*:
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds
> for length 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:77)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.extractFromValues(PartitionPruningMetadataExtractor.java:298)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.visit(PartitionPruningMetadataExtractor.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.visit(PartitionPruningMetadataExtractor.java:104)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteTableModify.accept(IgniteTableModify.java:145)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visitChild(IgniteRelShuttle.java:270)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.processNode(IgniteRelShuttle.java:260)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:64)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:60)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteSender.accept(IgniteSender.java:108)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.go(PartitionPruningMetadataExtractor.java:119)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPrunerImpl.apply(PartitionPrunerImpl.java:67)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.applyPartitionPruning(MappingServiceImpl.java:284)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.lambda$map0$3(MappingServiceImpl.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.map0(MappingServiceImpl.java:161)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.map(MappingServiceImpl.java:108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.execute(ExecutionServiceImpl.java:990)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:323)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:382)
> at
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.executePlan(SqlQueryProcessor.java:640)
> {noformat}
> *Plan*:
> {noformat}
> Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost
> = IgniteCost [rowCount=8.0, cpu=11.0, memory=7.0, io=2.0, network=6.0], id =
> 60
> ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=6.0, cpu=9.0, memory=6.0, io=1.0,
> network=5.0], id = 59
> Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=5.0, cpu=8.0, memory=1.0, io=1.0, network=5.0], id = 58
> TableModify(table=[[PUBLIC, TEST]], operation=[INSERT],
> flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost = Ignite
[jira] [Commented] (IGNITE-23034) Index restrictions are ignored on insert in a cluster of 3+ nodes
[
https://issues.apache.org/jira/browse/IGNITE-23034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875349#comment-17875349
]
Evgeny Stanilovsky commented on IGNITE-23034:
-
[~akhitrin] secondary index is not mean: unique index, question here - why it
differs for {1, 2} nodes.
> Index restrictions are ignored on insert in a cluster of 3+ nodes
> -
>
> Key: IGNITE-23034
> URL: https://issues.apache.org/jira/browse/IGNITE-23034
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Andrey Khitrin
>Priority: Critical
> Labels: ignite-3, index, transaction
>
> *Steps to reproduce*:
> 1. Start AI3 cluster with *3 or more* nodes
> 2. Create a simple table with an index:
> {code:sql}
> CREATE TABLE indexed_kids(id INTEGER, name VARCHAR(100), primary key (id))
> CREATE INDEX indexed_kids_index on indexed_kids using SORTED (name)
> INSERT INTO indexed_kids (id, name) VALUES (1, 'Europe')
> {code}
> 3. Run 2 parallel transactions that try to insert values with the same value
> for the *indexed column* (not PK!). For example:
> {code:sql}
> -- First transaction
> INSERT INTO indexed_kids (id, name) VALUES (9, 'Kolobok')
> -- Second transaction
> INSERT INTO indexed_kids (id, name) VALUES (12, 'Kolobok')
> {code}
> *Expected behavior*:
> Only the first transaction must success, and the second one must fail.
> *Actual behavior*:
> When a cluster size is 3 or greater, both transactions success, inserting two
> rows with the same value into an indexed column.
> Important:
> * For clusters with size of 1 or 2 nodes, behavior is correct (only 1
> transaction succeeds)
> * When we insert values with the same PK values, behavior is correct (only 1
> transaction succeeds)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22853) Sql. Repair CorrelatedSubqueryPlannerTest
[
https://issues.apache.org/jira/browse/IGNITE-22853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872349#comment-17872349
]
Evgeny Stanilovsky commented on IGNITE-22853:
-
[~korlov] can you make a review plz ?
> Sql. Repair CorrelatedSubqueryPlannerTest
> -
>
> Key: IGNITE-22853
> URL: https://issues.apache.org/jira/browse/IGNITE-22853
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Pereslegin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-22152
> org.apache.ignite.internal.sql.engine.planner.CorrelatedSubqueryPlannerTest#test
> fails with the following exception
> {noformat}
> org.opentest4j.AssertionFailedError:
> Expected :RecordType(INTEGER A, INTEGER B, INTEGER C, INTEGER D, INTEGER E,
> INTEGER __part)
> Actual :RecordType(INTEGER $f0, INTEGER $f1, INTEGER $f2, INTEGER $f3,
> INTEGER $f4, INTEGER $f5)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22853) Sql. Repair CorrelatedSubqueryPlannerTest
[
https://issues.apache.org/jira/browse/IGNITE-22853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22853:
---
Assignee: Evgeny Stanilovsky
> Sql. Repair CorrelatedSubqueryPlannerTest
> -
>
> Key: IGNITE-22853
> URL: https://issues.apache.org/jira/browse/IGNITE-22853
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> After IGNITE-22152
> org.apache.ignite.internal.sql.engine.planner.CorrelatedSubqueryPlannerTest#test
> fails with the following exception
> {noformat}
> org.opentest4j.AssertionFailedError:
> Expected :RecordType(INTEGER A, INTEGER B, INTEGER C, INTEGER D, INTEGER E,
> INTEGER __part)
> Actual :RecordType(INTEGER $f0, INTEGER $f1, INTEGER $f2, INTEGER $f3,
> INTEGER $f4, INTEGER $f5)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22943) Sql. SUBSTRING can return incorrect empty result for some parameters
[ https://issues.apache.org/jira/browse/IGNITE-22943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872008#comment-17872008 ] Evgeny Stanilovsky commented on IGNITE-22943: - patch is attached and approved in appropriate calcite issue. > Sql. SUBSTRING can return incorrect empty result for some parameters > > > Key: IGNITE-22943 > URL: https://issues.apache.org/jira/browse/IGNITE-22943 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > According to [1] issue - not expected results can be obtained from SUBSTRING > function. > Need to be fixed. > [1] CALCITE-6433 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22755) Sql. Bump calcite version
[
https://issues.apache.org/jira/browse/IGNITE-22755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871872#comment-17871872
]
Evgeny Stanilovsky edited comment on IGNITE-22755 at 8/8/24 8:27 AM:
-
But i see that mentioned calcite issue is still in progress ?
also we need to return check into
{noformat}
public void testSubstring()
...
assertQuery(String.format("SELECT SUBSTRING('1234567', %d, %d)",
Integer.MIN_VALUE, 10L + Integer.MAX_VALUE))
.returns("1234567").check();
{noformat}
note: this can be moved into logic tests after IGNITE-22755
cause it was fixed in CALCITE-6433
was (Author: zstan):
But i see that mentioned calcite issue is still in progress ?
also we need to return check into
{noformat}
public void testSubstring()
...
assertQuery(String.format("SELECT SUBSTRING('1234567', %d, %d)",
Integer.MIN_VALUE, 10L + Integer.MAX_VALUE))
.returns("1234567").check();
{noformat}
cause it was fixed in CALCITE-6433
> Sql. Bump calcite version
> -
>
> Key: IGNITE-22755
> URL: https://issues.apache.org/jira/browse/IGNITE-22755
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> In IGNITE-22735, new copy-pasted place has been introduced to
> IgniteSqlToRelConvertor. After the very same changes will be done in apache
> calcite (CALCITE-6471), we need to bump the version and remove introduced
> code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22755) Sql. Bump calcite version
[
https://issues.apache.org/jira/browse/IGNITE-22755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871872#comment-17871872
]
Evgeny Stanilovsky commented on IGNITE-22755:
-
But i see that mentioned calcite issue is still in progress ?
also we need to return check into
{noformat}
public void testSubstring()
...
assertQuery(String.format("SELECT SUBSTRING('1234567', %d, %d)",
Integer.MIN_VALUE, 10L + Integer.MAX_VALUE))
.returns("1234567").check();
{noformat}
cause it was fixed in CALCITE-6433
> Sql. Bump calcite version
> -
>
> Key: IGNITE-22755
> URL: https://issues.apache.org/jira/browse/IGNITE-22755
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> In IGNITE-22735, new copy-pasted place has been introduced to
> IgniteSqlToRelConvertor. After the very same changes will be done in apache
> calcite (CALCITE-6471), we need to bump the version and remove introduced
> code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22753) Sql. TestCluster. NPE in PrimaryKeyLookupPlannerTest and KeyValueModifyPlannerTest when run from IDE
[
https://issues.apache.org/jira/browse/IGNITE-22753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22753:
---
Assignee: Evgeny Stanilovsky
> Sql. TestCluster. NPE in PrimaryKeyLookupPlannerTest and
> KeyValueModifyPlannerTest when run from IDE
>
>
> Key: IGNITE-22753
> URL: https://issues.apache.org/jira/browse/IGNITE-22753
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: ignite-3
>
> Running all tests in org.apache.ignite.internal.sql.engine.planner from IDE,
> results in NPEs ( PrimaryKeyLookupPlannerTest and KeyValueModifyPlannerTest).
> {noformat}
> ava.lang.NullPointerException
> at
> org.apache.ignite.internal.metrics.MetricManagerImpl.registerSource(MetricManagerImpl.java:133)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.start(PrepareServiceImpl.java:203)
> at java.base/java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.ignite.internal.sql.engine.framework.TestCluster.start(TestCluster.java:85)
> at
> org.apache.ignite.internal.sql.engine.planner.KeyValueModifyPlannerTest.start(KeyValueModifyPlannerTest.java:60)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> Suppressed: java.lang.NullPointerException
> at
> org.apache.ignite.internal.metrics.MetricManagerImpl.unregisterSource(MetricManagerImpl.java:138)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.stop(PrepareServiceImpl.java:213)
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$closeAll$0(IgniteUtils.java:564)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> org.apache.ignite.internal.util.IgniteUtils.closeAll(IgniteUtils.java:562)
> at
> org.apache.ignite.internal.util.IgniteUtils.closeAll(IgniteUtils.java:585)
> at
> org.apache.ignite.internal.sql.engine.framework.TestCluster.stop(TestCluster.java:102)
> at
> org.apache.ignite.internal.sql.engine.planner.KeyValueModifyPlannerTest.stop(KeyValueModifyPlannerTest.java:65)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> ... 1 more
> {noformat}
> When these tests are run individually there is no such error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22943) Sql. SUBSTRING can return incorrect empty result for some parameters
Evgeny Stanilovsky created IGNITE-22943: --- Summary: Sql. SUBSTRING can return incorrect empty result for some parameters Key: IGNITE-22943 URL: https://issues.apache.org/jira/browse/IGNITE-22943 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky According to [1] issue - not expected results can be obtained from SUBSTRING function. Need to be fixed. [1] CALCITE-6433 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22943) Sql. SUBSTRING can return incorrect empty result for some parameters
[ https://issues.apache.org/jira/browse/IGNITE-22943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-22943: --- Assignee: Evgeny Stanilovsky > Sql. SUBSTRING can return incorrect empty result for some parameters > > > Key: IGNITE-22943 > URL: https://issues.apache.org/jira/browse/IGNITE-22943 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > According to [1] issue - not expected results can be obtained from SUBSTRING > function. > Need to be fixed. > [1] CALCITE-6433 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22892) Sql. NumericCaseTypeCoercionTest duplicates test case fix
[
https://issues.apache.org/jira/browse/IGNITE-22892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22892:
---
Assignee: Evgeny Stanilovsky
> Sql. NumericCaseTypeCoercionTest duplicates test case fix
> -
>
> Key: IGNITE-22892
> URL: https://issues.apache.org/jira/browse/IGNITE-22892
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NumericCaseTypeCoercionTest failed with:
> {noformat}
> java.lang.AssertionError: There are duplicate pairs. Remove them
> Expected: an empty collection
> but: <[DECIMAL_2_0_DECIMAL_2_0, DECIMAL_2_0_DECIMAL_3_1,
> DECIMAL_2_0_DECIMAL_5_3, DECIMAL_2_0_DECIMAL_5_0, DECIMAL_2_0_DECIMAL_6_1,
> DECIMAL_2_0_DECIMAL_8_3, DECIMAL_2_0_REAL, DECIMAL_2_0_DOUBLE]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22892) Sql. NumericCaseTypeCoercionTest duplicates test case fix
Evgeny Stanilovsky created IGNITE-22892:
---
Summary: Sql. NumericCaseTypeCoercionTest duplicates test case fix
Key: IGNITE-22892
URL: https://issues.apache.org/jira/browse/IGNITE-22892
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
NumericCaseTypeCoercionTest failed with:
{noformat}
java.lang.AssertionError: There are duplicate pairs. Remove them
Expected: an empty collection
but: <[DECIMAL_2_0_DECIMAL_2_0, DECIMAL_2_0_DECIMAL_3_1,
DECIMAL_2_0_DECIMAL_5_3, DECIMAL_2_0_DECIMAL_5_0, DECIMAL_2_0_DECIMAL_6_1,
DECIMAL_2_0_DECIMAL_8_3, DECIMAL_2_0_REAL, DECIMAL_2_0_DOUBLE]>
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22890) Sql. Improve SqlTestUtils#generateValueByType for DECIMAL type with defined precision\scale
[
https://issues.apache.org/jira/browse/IGNITE-22890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22890:
Summary: Sql. Improve SqlTestUtils#generateValueByType for DECIMAL type
with defined precision\scale (was: Sql. Improve )
> Sql. Improve SqlTestUtils#generateValueByType for DECIMAL type with defined
> precision\scale
> ---
>
> Key: IGNITE-22890
> URL: https://issues.apache.org/jira/browse/IGNITE-22890
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> At this time SqlTestUtils#generateValueByType is used in *TypeCoercionTest
> test, this function is not take into account precision\scale for DECIMAL
> types and returns:
> {noformat}
> case DECIMAL:
> return BigDecimal.valueOf(base + ((double) base /
> 1000)).add(BigDecimal.valueOf(Long.MAX_VALUE));
> {noformat}
> Seems we need to fix it, for more accurate tests approach.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22890) Sql. Improve
[
https://issues.apache.org/jira/browse/IGNITE-22890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22890:
Summary: Sql. Improve (was: Sql. Fix serialisation\deserealisation check
in AbstractPlannerTest.checkSplitAndSerialization)
> Sql. Improve
> -
>
> Key: IGNITE-22890
> URL: https://issues.apache.org/jira/browse/IGNITE-22890
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> At this time SqlTestUtils#generateValueByType is used in *TypeCoercionTest
> test, this function is not take into account precision\scale for DECIMAL
> types and returns:
> {noformat}
> case DECIMAL:
> return BigDecimal.valueOf(base + ((double) base /
> 1000)).add(BigDecimal.valueOf(Long.MAX_VALUE));
> {noformat}
> Seems we need to fix it, for more accurate tests approach.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22890) Sql. Fix serialisation\deserealisation check in AbstractPlannerTest.checkSplitAndSerialization
Evgeny Stanilovsky created IGNITE-22890:
---
Summary: Sql. Fix serialisation\deserealisation check in
AbstractPlannerTest.checkSplitAndSerialization
Key: IGNITE-22890
URL: https://issues.apache.org/jira/browse/IGNITE-22890
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
At this time SqlTestUtils#generateValueByType is used in *TypeCoercionTest
test, this function is not take into account precision\scale for DECIMAL types
and returns:
{noformat}
case DECIMAL:
return BigDecimal.valueOf(base + ((double) base /
1000)).add(BigDecimal.valueOf(Long.MAX_VALUE));
{noformat}
Seems we need to fix it, for more accurate tests approach.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22875) Add info on limitations of outer joins to doc
[ https://issues.apache.org/jira/browse/IGNITE-22875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-22875: Ignite Flags: (was: Docs Required,Release Notes Required) > Add info on limitations of outer joins to doc > - > > Key: IGNITE-22875 > URL: https://issues.apache.org/jira/browse/IGNITE-22875 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > Ignite has some limitations on outer joins. We need to add them to > documentation. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22865) NPE is swallowed in entrails of mapToPublicException
Evgeny Stanilovsky created IGNITE-22865:
---
Summary: NPE is swallowed in entrails of mapToPublicException
Key: IGNITE-22865
URL: https://issues.apache.org/jira/browse/IGNITE-22865
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
NPE raised in internal implementation is not visible in final upper exception,
internal stack trace from log (probably it`s client side problem):
{noformat}
java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-6
TraceId:350d6455-4b5a-4ff2-860e-707b574ac72a
at
org.apache.ignite.internal.tx.impl.TransactionsExceptionMapperUtil.lambda$convertToPublicFuture$0(TransactionsExceptionMapperUtil.java:51)
~[main/:?]
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
[?:?]
...
Caused by: org.apache.ignite.tx.TransactionException
at
org.apache.ignite.internal.tx.impl.TransactionsExceptionMapperUtil.lambda$mapToPublicTransactionException$1(TransactionsExceptionMapperUtil.java:71)
~[main/:?]
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapCheckingResultIsPublic(IgniteExceptionMapperUtil.java:141)
~[main/:?]
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:137)
~[main/:?]
at
org.apache.ignite.internal.tx.impl.TransactionsExceptionMapperUtil.mapToPublicTransactionException(TransactionsExceptionMapperUtil.java:71)
~[main/:?]
... 31 more
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$prepareFinish$10(TxManagerImpl.java:597)
~[main/:?]
{noformat}
final (test raised, client side) exception looks like:
{noformat}
org.apache.ignite.tx.TransactionException: IGN-TX-6
TraceId:350d6455-4b5a-4ff2-860e-707b574ac72a
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
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.ViewUtils.copyExceptionWithCauseIfPossible(ViewUtils.java:91)
at
org.apache.ignite.internal.util.ViewUtils.ensurePublicException(ViewUtils.java:71)
at org.apache.ignite.internal.util.ViewUtils.sync(ViewUtils.java:54)
at
org.apache.ignite.internal.client.tx.ClientTransaction.commit(ClientTransaction.java:95)
at
org.apache.ignite.internal.client.tx.ClientLazyTransaction.commit(ClientLazyTransaction.java:53)
at
org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.test0(ItIgniteNodeRestartTest.java:1168)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: org.apache.ignite.tx.TransactionException: IGN-TX-6
TraceId:350d6455-4b5a-4ff2-860e-707b574ac72a
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
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)
{noformat}
thus no NPE mention is found here.
fast reproducer :
{noformat}
@Test
public void test01() {
startNodes(1);
IgniteClient igniteClient =
IgniteClient.builder().addresses("127.0.0.1:10800").build();
igniteClient.sql().execute(null, "create table t0(id int primary key,
val int)");
Transaction tx = igniteClient.transactions().begin();
ResultSet res = igniteClient.sql().execute(tx, "select * from
t0");
res.hasNext();
tx.commit();
}
{noformat}
and change DistributedQueryManager#enlistPartitions change enlist
implementation on IgniteRelShuttle anonymous class like :
{noformat}
tx.enlist(tablePartId,
new IgniteBiTuple<>(
/*topSrvc.getByConsistentId(assignment.name())*/null,
assignment.enlistmentConsistencyToken())
);
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22861) Sql. Calculation for mapOnBackups parameter erased.
Evgeny Stanilovsky created IGNITE-22861:
---
Summary: Sql. Calculation for mapOnBackups parameter erased.
Key: IGNITE-22861
URL: https://issues.apache.org/jira/browse/IGNITE-22861
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
After [1] was implemented it`s become possible to run queries on backup nodes
but for now it erased, check implementation:
{noformat}
boolean mapOnBackups = tx.isReadOnly();
MappingParameters mappingParameters =
MappingParameters.create(ctx.parameters(), mapOnBackups);
{noformat}
{noformat}
public static MappingParameters create(Object[] dynamicParameters, boolean
mapOnBackups) {
if (dynamicParameters.length == 0) {
return EMPTY;
} else {
return new MappingParameters(dynamicParameters, mapOnBackups);
}
}
{noformat}
[1] IGNITE-22466 Sql. Support mapping to non-primary replicas
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22785) Sql. Partition pruning. Insert. ArrayIndexOutOfBoundsException when key column literal overflows
[
https://issues.apache.org/jira/browse/IGNITE-22785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869530#comment-17869530
]
Evgeny Stanilovsky commented on IGNITE-22785:
-
[~korlov], [~mzhuravkov] can you make a review plz ?
> Sql. Partition pruning. Insert. ArrayIndexOutOfBoundsException when key
> column literal overflows
>
>
> Key: IGNITE-22785
> URL: https://issues.apache.org/jira/browse/IGNITE-22785
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> 1. Disable KeyValueModifyPlan.
> 2. Run the following test case:
> {noformat}
> @Test
> public void dmlOps() {
> sql("CREATE TABLE test (id INT PRIMARY KEY, val INT);");
> sql(String.format("INSERT INTO test VALUES(%d, 1)", Long.MAX_VALUE));
> }
> {noformat}
> *Expected error*: SMALLINT out of range
> *Actual error*:
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds
> for length 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:77)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.extractFromValues(PartitionPruningMetadataExtractor.java:298)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.visit(PartitionPruningMetadataExtractor.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.visit(PartitionPruningMetadataExtractor.java:104)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteTableModify.accept(IgniteTableModify.java:145)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visitChild(IgniteRelShuttle.java:270)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.processNode(IgniteRelShuttle.java:260)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:64)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:60)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteSender.accept(IgniteSender.java:108)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.go(PartitionPruningMetadataExtractor.java:119)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPrunerImpl.apply(PartitionPrunerImpl.java:67)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.applyPartitionPruning(MappingServiceImpl.java:284)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.lambda$map0$3(MappingServiceImpl.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.map0(MappingServiceImpl.java:161)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.map(MappingServiceImpl.java:108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.execute(ExecutionServiceImpl.java:990)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:323)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:382)
> at
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.executePlan(SqlQueryProcessor.java:640)
> {noformat}
> *Plan*:
> {noformat}
> Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost
> = IgniteCost [rowCount=8.0, cpu=11.0, memory=7.0, io=2.0, network=6.0], id =
> 60
> ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=6.0, cpu=9.0, memory=6.0, io=1.0,
> network=5.0], id = 59
> Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=5.0, cpu=8.0, memory=1.0, io=1.0, network=5.0], id = 58
> TableModify(table=[[PUBLIC, TEST]], operation=[INSERT],
> flattened=[false], tableId=[
[jira] [Updated] (IGNITE-22855) Sql. Missing ClusterNode can be involved into tx enlist
[
https://issues.apache.org/jira/browse/IGNITE-22855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22855:
Epic Link: IGNITE-22815
> Sql. Missing ClusterNode can be involved into tx enlist
> ---
>
> Key: IGNITE-22855
> URL: https://issues.apache.org/jira/browse/IGNITE-22855
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> DistributedQueryManager#sendFragments enlists partitions:
> {noformat}
> if (!tx.isReadOnly()) {
> for (MappedFragment mappedFragment : mappedFragments) {
> enlistPartitions(mappedFragment, tx);
> }
> }
> {noformat}
> and obtain ClusterNode from topologyService, here:
> IgniteRelShuttle#enlist
> but node can leave topology at that moment and *null* will return in such a
> case.
> {noformat}
> @Nullable ClusterNode getByConsistentId(String consistentId);
> {noformat}
> need to cover such a case and re run existing query
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22855) Sql. Missing ClusterNode can be involved into tx enlist
Evgeny Stanilovsky created IGNITE-22855:
---
Summary: Sql. Missing ClusterNode can be involved into tx enlist
Key: IGNITE-22855
URL: https://issues.apache.org/jira/browse/IGNITE-22855
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
DistributedQueryManager#sendFragments enlists partitions:
{noformat}
if (!tx.isReadOnly()) {
for (MappedFragment mappedFragment : mappedFragments) {
enlistPartitions(mappedFragment, tx);
}
}
{noformat}
and obtain ClusterNode from topologyService, here:
IgniteRelShuttle#enlist
but node can leave topology at that moment and *null* will return in such a
case.
{noformat}
@Nullable ClusterNode getByConsistentId(String consistentId);
{noformat}
need to cover such a case and re run existing query
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22768) Sql. Send execution fragment into topology absent node
[
https://issues.apache.org/jira/browse/IGNITE-22768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22768:
Epic Link: IGNITE-22815
> Sql. Send execution fragment into topology absent node
> --
>
> Key: IGNITE-22768
> URL: https://issues.apache.org/jira/browse/IGNITE-22768
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> It can happen that in mapping phase node still in topology, while a bit after
> - already not, in such a case fragments will be send into non existing node
> and exception will raised. Seems such recoverable situation need to be
> handled.
> Exception raised:
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:3c6faf2a-863d-4342-83ec-0565c1049b2c Unable to send fragment
> [targetNode=iinrt_t_1, fragmentId=1, cause=Recipient consistent ID cannot be
> resolved: iinrt_t_1]
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> 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.client.sql.ClientSql.execute(ClientSql.java:100)
> at
> org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.test0(ItIgniteNodeRestartTest.java:1133)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:3c6faf2a-863d-4342-83ec-0565c1049b2c Unable to send fragment
> [targetNode=iinrt_t_1, fragmentId=1, cause=Recipient consistent ID cannot be
> resolved: iinrt_t_1]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2094)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:428)
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:247)
> at
> java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:3c6faf2a-863d-4342-83ec-0565c1049b2c Unable to send fragment
> [targetNode=iinrt_t_1, fragmentId=1, cause=Recipient consistent ID cannot be
> resolved: iinrt_t_1]
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> 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.client.TcpClientChannel.readError(TcpClientChannel.java:519)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:406)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22816) Sql. Investigate all possible cases during sql processing on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-22816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-22816: --- Assignee: Evgeny Stanilovsky > Sql. Investigate all possible cases during sql processing on unstable topology > -- > > Key: IGNITE-22816 > URL: https://issues.apache.org/jira/browse/IGNITE-22816 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Need to investigate and fill appropriate issues for case while sql is > processing on unstable topology. Use cases can be divided into recoverable > and not recoverable, thus in all cases when it possible ignite need to > process request and throw informative exception in opposite. > Need to take into account: dataNodesAutoAdjust, dataNodesAutoAdjustScaleDown, > cache invalidation for plan mapping and so on... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22815) Sql must process unstable topology cases and recovery request if it possible
[ https://issues.apache.org/jira/browse/IGNITE-22815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-22815: --- Assignee: (was: Evgeny Stanilovsky) > Sql must process unstable topology cases and recovery request if it possible > > > Key: IGNITE-22815 > URL: https://issues.apache.org/jira/browse/IGNITE-22815 > Project: Ignite > Issue Type: Epic > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > During cluster life cycle this is normal that some nodes are leaving topology > and possibly come back at future. Ignite need to process such cases during a > continuous stream of sql requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22815) Sql must process unstable topology cases and recovery request if it possible
[ https://issues.apache.org/jira/browse/IGNITE-22815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-22815: --- Assignee: Evgeny Stanilovsky > Sql must process unstable topology cases and recovery request if it possible > > > Key: IGNITE-22815 > URL: https://issues.apache.org/jira/browse/IGNITE-22815 > Project: Ignite > Issue Type: Epic > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > During cluster life cycle this is normal that some nodes are leaving topology > and possibly come back at future. Ignite need to process such cases during a > continuous stream of sql requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22785) Sql. Partition pruning. Insert. ArrayIndexOutOfBoundsException when key column literal overflows
[
https://issues.apache.org/jira/browse/IGNITE-22785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22785:
---
Assignee: Evgeny Stanilovsky
> Sql. Partition pruning. Insert. ArrayIndexOutOfBoundsException when key
> column literal overflows
>
>
> Key: IGNITE-22785
> URL: https://issues.apache.org/jira/browse/IGNITE-22785
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Reproducer:
> 1. Disable KeyValueModifyPlan.
> 2. Run the following test case:
> {noformat}
> @Test
> public void dmlOps() {
> sql("CREATE TABLE test (id INT PRIMARY KEY, val INT);");
> sql(String.format("INSERT INTO test VALUES(%d, 1)", Long.MAX_VALUE));
> }
> {noformat}
> *Expected error*: SMALLINT out of range
> *Actual error*:
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds
> for length 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:77)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.extractFromValues(PartitionPruningMetadataExtractor.java:298)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.visit(PartitionPruningMetadataExtractor.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.visit(PartitionPruningMetadataExtractor.java:104)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteTableModify.accept(IgniteTableModify.java:145)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visitChild(IgniteRelShuttle.java:270)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.processNode(IgniteRelShuttle.java:260)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:64)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteRelShuttle.visit(IgniteRelShuttle.java:60)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteSender.accept(IgniteSender.java:108)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPruningMetadataExtractor.go(PartitionPruningMetadataExtractor.java:119)
> at
> org.apache.ignite.internal.sql.engine.prepare.pruning.PartitionPrunerImpl.apply(PartitionPrunerImpl.java:67)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.applyPartitionPruning(MappingServiceImpl.java:284)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.lambda$map0$3(MappingServiceImpl.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.map0(MappingServiceImpl.java:161)
> at
> org.apache.ignite.internal.sql.engine.exec.mapping.MappingServiceImpl.map(MappingServiceImpl.java:108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.execute(ExecutionServiceImpl.java:990)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:323)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:382)
> at
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.executePlan(SqlQueryProcessor.java:640)
> {noformat}
> *Plan*:
> {noformat}
> Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost
> = IgniteCost [rowCount=8.0, cpu=11.0, memory=7.0, io=2.0, network=6.0], id =
> 60
> ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=6.0, cpu=9.0, memory=6.0, io=1.0,
> network=5.0], id = 59
> Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=5.0, cpu=8.0, memory=1.0, io=1.0, network=5.0], id = 58
> TableModify(table=[[PUBLIC, TEST]], operation=[INSERT],
> flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=4.0, cpu=7.0, memory=1.0, io=1.0, network=1.0], id = 57
> TrimExchange(distribution=[affinity[tableId=9, zoneId=9][0]]):
> r
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17868670#comment-17868670
]
Evgeny Stanilovsky commented on IGNITE-22635:
-
I suppose this issue need to be reworked, it`s not about Optimization error,
it`s about confusion upper level error message, need to be "out of range".
> 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
>Priority: Major
> Labels: ignite-3
>
> 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(RexToLixTranslat
[jira] [Commented] (IGNITE-22817) Sql. Align rule of conversion between numerics
[
https://issues.apache.org/jira/browse/IGNITE-22817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868579#comment-17868579
]
Evgeny Stanilovsky commented on IGNITE-22817:
-
[~korlov] looks good !
> Sql. Align rule of conversion between numerics
> --
>
> Key: IGNITE-22817
> URL: https://issues.apache.org/jira/browse/IGNITE-22817
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Class {{IgniteMath}} contains set of methods to do conversion from one
> numeric to another with bound check. The problem is that rules of bound check
> differs from one type pair to another: some pairs has strict rules, some
> pairs allow to have decimal part of arbitrary size, some pairs do bound check
> after rounding initial value with HALF UP strategy.
> We need to make bound check consistent for all type pairs. Since we are going
> to truncate decimal part during conversion to. integers, it's suggested to do
> bound check accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22816) Sql. Investigate all possible cases during sql processing on unstable topology
Evgeny Stanilovsky created IGNITE-22816: --- Summary: Sql. Investigate all possible cases during sql processing on unstable topology Key: IGNITE-22816 URL: https://issues.apache.org/jira/browse/IGNITE-22816 Project: Ignite Issue Type: Task Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Need to investigate and fill appropriate issues for case while sql is processing on unstable topology. Use cases can be divided into recoverable and not recoverable, thus in all cases when it possible ignite need to process request and throw informative exception in opposite. Need to take into account: dataNodesAutoAdjust, dataNodesAutoAdjustScaleDown, cache invalidation for plan mapping and so on... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22815) Sql must process unstable topology cases and recovery request if it possible
Evgeny Stanilovsky created IGNITE-22815: --- Summary: Sql must process unstable topology cases and recovery request if it possible Key: IGNITE-22815 URL: https://issues.apache.org/jira/browse/IGNITE-22815 Project: Ignite Issue Type: Epic Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky During cluster life cycle this is normal that some nodes are leaving topology and possibly come back at future. Ignite need to process such cases during a continuous stream of sql requests. -- 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 ] Evgeny Stanilovsky reassigned IGNITE-22580: --- Assignee: Evgeny Stanilovsky > 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: Evgeny Stanilovsky >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] [Commented] (IGNITE-22792) REPLICATED table left join PARTITIONED table return error resultset with PARALLELISM is set
[
https://issues.apache.org/jira/browse/IGNITE-22792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867962#comment-17867962
]
Evgeny Stanilovsky commented on IGNITE-22792:
-
yep, this is a bug, also take into account [1]
[1] https://issues.apache.org/jira/browse/IGNITE-22789
> REPLICATED table left join PARTITIONED table return error resultset with
> PARALLELISM is set
> ---
>
> Key: IGNITE-22792
> URL: https://issues.apache.org/jira/browse/IGNITE-22792
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.16
>Reporter: YuJue Li
>Priority: Major
> Fix For: 2.17
>
>
> start 2 nodes by ignite.sh and execute the following SQL:
> CREATE TABLE TEST_B (
> PORT_ID VARCHAR,
> OUT_SEC_ID VARCHAR,
> CONSTRAINT PORT_ID PRIMARY KEY (PORT_ID)
> ) WITH "TEMPLATE=REPLICATED";
>
> CREATE TABLE TEST_C (
> SEC_ID VARCHAR,
> SEC_NAME VARCHAR,
> CONSTRAINT SEC_ID PRIMARY KEY (SEC_ID)
> ) WITH "TEMPLATE=PARTITIONED,PARALLELISM=6";
>
>
> INSERT INTO TEST_B VALUES ('PORT1','600030');
>
> INSERT INTO TEST_C VALUES ('600030','');
>
> SELECT tb1.PORT_ID,
> tb2.SEC_ID,
> tb2.SEC_NAME
> FROM TEST_B tb1 LEFT JOIN TEST_C tb2 ON tb1.OUT_SEC_ID=tb2.SEC_ID;
>
> Normally, this SQL should return one row, but it returned 6 rows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22789) Throw informative exception when both partitioned and replicated caches are participate in join operation
Evgeny Stanilovsky created IGNITE-22789: --- Summary: 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 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] [Resolved] (IGNITE-22584) Cluster load balancing when the second node (non-CMG) is killed doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-22584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky resolved IGNITE-22584.
-
Release Note: root case of a problem is attached
Resolution: Fixed
> Cluster load balancing when the second node (non-CMG) is killed doesn't work
>
>
> Key: IGNITE-22584
> URL: https://issues.apache.org/jira/browse/IGNITE-22584
> Project: Ignite
> Issue Type: Bug
> Components: persistence, sql
>Reporter: Anatoli Karman
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> *Steps to reproduce:*
> # Start cluster with 2 nodes running locally.
> # Make connection like this:
> {code:java}
> try (IgniteClient igniteClient = IgniteClient.builder().retryPolicy(new
> RetryLimitPolicy()).addresses(thinClientEndpoints.toArray(new
> String[]{"localhost:10800","localhost:10801"})).build()) {
> try (Session session = igniteClient.sql().createSession()) {
> //code here
> }
> } {code}
> 3. Create table with replication 2
> 4. Execute insert 1 row and select from the table.
> 5. Kill the second node (non-CMG)
> 6. Execute select from the table.
> *Expected:*
> Cluster works with one node.
> *Actual:*
> The exception on select after first node is killed, the select is not
> executed.
> {code:java}
> org.opentest4j.AssertionFailedError: Select after node is killed ==>
> Unexpected exception thrown: org.apache.ignite.sql.SqlException: Unable to
> request next batch:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: /172.120.6.2:3345
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.createAssertionFailedError(AssertDoesNotThrow.java:84)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:53)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:40)
> at
> app//org.junit.jupiter.api.Assertions.assertDoesNotThrow(Assertions.java:3183)
> at
> app//org.gridgain.ai3tests.tests.ConnectionAfterNodeIsKilledTest.testThinClientConnectionToMultipleHostAfter1NodeIsKilled(ConnectionAfterNodeIsKilledTest.java:128)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.base@11.0.17/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:e1244baf-7528-40e5-aa3a-ec8306c4c41a Unable to request next batch:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: /172.120.6.2:3345
> at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:789)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:723)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:658)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> app//org.apache.ignite.internal.client.sql.ClientSql.execute(ClientSql.java:102)
> at
> app//org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.lambda$executeQuery$0(ThinClientSteps.java:64)
> at app//io.qameta.allure.Allure.lambda$step$1(Allure.java:127)
> at app//io.qameta.allure.Allure.step(Allure.java:181)
> at app//io.qameta.allure.Allure.step(Allure.java:125)
> at
> app//org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.executeQuery(ThinClientSteps.java:64)
> at
> app//org.gridgain.ai3tests.tests.TestUtils.selectAll(TestUtils.java:174)
> at
> app//org.gridgain.ai3tests.tests.ConnectionAfterNodeIsKilledTest.lambda$testThinClientConnectionToMultipleHostAfter1NodeIsKilled$0(ConnectionAfterNodeIsKilledTest.java:129)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:49)
> ... 8 more
> Caused by: java.util.concurrent.CompletionException:
> org.apache.
[jira] [Created] (IGNITE-22768) Sql. Send execution fragment into topology absent node
Evgeny Stanilovsky created IGNITE-22768:
---
Summary: Sql. Send execution fragment into topology absent node
Key: IGNITE-22768
URL: https://issues.apache.org/jira/browse/IGNITE-22768
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
It can happen that in mapping phase node still in topology, while a bit after -
already not, in such a case fragments will be send into non existing node and
exception will raised. Seems such recoverable situation need to be handled.
Exception raised:
{noformat}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:3c6faf2a-863d-4342-83ec-0565c1049b2c Unable to send fragment
[targetNode=iinrt_t_1, fragmentId=1, cause=Recipient consistent ID cannot be
resolved: iinrt_t_1]
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
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.client.sql.ClientSql.execute(ClientSql.java:100)
at
org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.test0(ItIgniteNodeRestartTest.java:1133)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: java.util.concurrent.CompletionException:
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:3c6faf2a-863d-4342-83ec-0565c1049b2c Unable to send fragment
[targetNode=iinrt_t_1, fragmentId=1, cause=Recipient consistent ID cannot be
resolved: iinrt_t_1]
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2094)
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:428)
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:247)
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:3c6faf2a-863d-4342-83ec-0565c1049b2c Unable to send fragment
[targetNode=iinrt_t_1, fragmentId=1, cause=Recipient consistent ID cannot be
resolved: iinrt_t_1]
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
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.client.TcpClientChannel.readError(TcpClientChannel.java:519)
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:406)
{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
]
Evgeny Stanilovsky updated IGNITE-22716:
Component/s: sql
> 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
>
> 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] [Assigned] (IGNITE-22584) Cluster load balancing when the second node (non-CMG) is killed doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-22584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22584:
---
Assignee: Evgeny Stanilovsky
> Cluster load balancing when the second node (non-CMG) is killed doesn't work
>
>
> Key: IGNITE-22584
> URL: https://issues.apache.org/jira/browse/IGNITE-22584
> Project: Ignite
> Issue Type: Bug
> Components: persistence, sql
>Reporter: Anatoli Karman
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> *Steps to reproduce:*
> # Start cluster with 2 nodes running locally.
> # Make connection like this:
> {code:java}
> try (IgniteClient igniteClient = IgniteClient.builder().retryPolicy(new
> RetryLimitPolicy()).addresses(thinClientEndpoints.toArray(new
> String[]{"localhost:10800","localhost:10801"})).build()) {
> try (Session session = igniteClient.sql().createSession()) {
> //code here
> }
> } {code}
> 3. Create table with replication 2
> 4. Execute insert 1 row and select from the table.
> 5. Kill the second node (non-CMG)
> 6. Execute select from the table.
> *Expected:*
> Cluster works with one node.
> *Actual:*
> The exception on select after first node is killed, the select is not
> executed.
> {code:java}
> org.opentest4j.AssertionFailedError: Select after node is killed ==>
> Unexpected exception thrown: org.apache.ignite.sql.SqlException: Unable to
> request next batch:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: /172.120.6.2:3345
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.createAssertionFailedError(AssertDoesNotThrow.java:84)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:53)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:40)
> at
> app//org.junit.jupiter.api.Assertions.assertDoesNotThrow(Assertions.java:3183)
> at
> app//org.gridgain.ai3tests.tests.ConnectionAfterNodeIsKilledTest.testThinClientConnectionToMultipleHostAfter1NodeIsKilled(ConnectionAfterNodeIsKilledTest.java:128)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.base@11.0.17/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:e1244baf-7528-40e5-aa3a-ec8306c4c41a Unable to request next batch:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: /172.120.6.2:3345
> at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:789)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:723)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:658)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> app//org.apache.ignite.internal.client.sql.ClientSql.execute(ClientSql.java:102)
> at
> app//org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.lambda$executeQuery$0(ThinClientSteps.java:64)
> at app//io.qameta.allure.Allure.lambda$step$1(Allure.java:127)
> at app//io.qameta.allure.Allure.step(Allure.java:181)
> at app//io.qameta.allure.Allure.step(Allure.java:125)
> at
> app//org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.executeQuery(ThinClientSteps.java:64)
> at
> app//org.gridgain.ai3tests.tests.TestUtils.selectAll(TestUtils.java:174)
> at
> app//org.gridgain.ai3tests.tests.ConnectionAfterNodeIsKilledTest.lambda$testThinClientConnectionToMultipleHostAfter1NodeIsKilled$0(ConnectionAfterNodeIsKilledTest.java:129)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:49)
> ... 8 more
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
[jira] [Assigned] (IGNITE-22698) Sql. Extend test coverage for numeric comparison with literal wider than numeric type
[
https://issues.apache.org/jira/browse/IGNITE-22698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22698:
---
Assignee: Evgeny Stanilovsky
> Sql. Extend test coverage for numeric comparison with literal wider than
> numeric type
> -
>
> Key: IGNITE-22698
> URL: https://issues.apache.org/jira/browse/IGNITE-22698
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to cover cases where literal or numeric value, used in predicate is
> wider than column\expression type. E.g:
> {noformat}
> create table tiny(v TINYINT);
> insert into tiny values(127);
> SELECT * FROM tiny WHERE v < 300;
> SELECT * FROM tiny WHERE v NOT IN (300, 1000);
> {noformat}
> Also seems sql with mixed exact numeric and approx literal predicates need to
> fail.
> {noformat}
> create table tiny(v TINYINT);
> insert into tiny values(127);
> SELECT * FROM tiny WHERE v < '3.1'; <-- need to fail
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22698) Sql. Extend test coverage for numeric comparison with literal wider than numeric type
Evgeny Stanilovsky created IGNITE-22698:
---
Summary: Sql. Extend test coverage for numeric comparison with
literal wider than numeric type
Key: IGNITE-22698
URL: https://issues.apache.org/jira/browse/IGNITE-22698
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Need to cover cases where literal or numeric value, used in predicate is wider
than column\expression type. E.g:
{noformat}
create table tiny(v TINYINT);
insert into tiny values(127);
SELECT * FROM tiny WHERE v < 300;
SELECT * FROM tiny WHERE v NOT IN (300, 1000);
{noformat}
Also seems sql with mixed exact numeric and approx literal predicates need to
fail.
{noformat}
create table tiny(v TINYINT);
insert into tiny values(127);
SELECT * FROM tiny WHERE v < '3.1'; <-- need to fail
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22444) Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
[
https://issues.apache.org/jira/browse/IGNITE-22444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22444:
Description:
According to standard:
{noformat}
Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
to the other type, subject to truncation conditions
{noformat}
Thus i expect such expressions need to be processed correctly, but it fails:
{noformat}
create table tiny(v TINYINT);
insert into tiny values(127);
SELECT * FROM tiny WHERE v < '300';
{noformat}
{noformat}
Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for type
TINYINT
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
{noformat}
Check: AbstractTypeCoercion#commonTypeForBinaryComparison
was:
According to standard:
{noformat}
Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
to the other type, subject to truncation conditions
{noformat}
Thus i expect such expressions need to be processed correctly, but it fails:
{noformat}
create table tiny(v TINYINT);
insert into tiny values(127);
SELECT * FROM tiny WHERE v < '300';
{noformat}
{noformat}
Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for type
TINYINT
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
{noformat}
Seems such a problem was introduced here [1]
[1] IGNITE-18662
> Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
> -
>
> Key: IGNITE-22444
> URL: https://issues.apache.org/jira/browse/IGNITE-22444
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Time Spent: 3h
> Remaining Estimate: 0h
>
> According to standard:
> {noformat}
> Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
> to the other type, subject to truncation conditions
> {noformat}
> Thus i expect such expressions need to be processed correctly, but it fails:
> {noformat}
> create table tiny(v TINYINT);
> insert into tiny values(127);
> SELECT * FROM tiny WHERE v < '300';
> {noformat}
> {noformat}
> Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
> TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for
> type TINYINT
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
> {noformat}
> Check: AbstractTypeCoercion#commonTypeForBinaryComparison
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22697) Sql. Comparison on BIGINT cast brings overflow
Evgeny Stanilovsky created IGNITE-22697:
---
Summary: 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
{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] [Resolved] (IGNITE-22640) Sql. Improve type derivation for dynamic parameters.
[
https://issues.apache.org/jira/browse/IGNITE-22640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky resolved IGNITE-22640.
-
Resolution: Not A Problem
> Sql. Improve type derivation for dynamic parameters.
>
>
> Key: IGNITE-22640
> URL: https://issues.apache.org/jira/browse/IGNITE-22640
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> sql("create table tiny(v TINYINT);");
> sql("insert into tiny values(127);");
> // passed
> assertQuery("SELECT * FROM tiny WHERE v IN
> (?)").withParam(127).returns((byte) 127).check();
> // throw exception
> assertQuery("SELECT * FROM tiny WHERE v IN
> (?)").withParam("127").returns((byte) 127).check();
> {noformat}
> {noformat}
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Assignment
> from VARCHAR to DECIMAL(32767, 16383) can not be performed. Dynamic parameter
> requires adding explicit type cast
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22640) Sql. Improve type derivation for dynamic parameters.
Evgeny Stanilovsky created IGNITE-22640:
---
Summary: Sql. Improve type derivation for dynamic parameters.
Key: IGNITE-22640
URL: https://issues.apache.org/jira/browse/IGNITE-22640
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
{noformat}
sql("create table tiny(v TINYINT);");
sql("insert into tiny values(127);");
// passed
assertQuery("SELECT * FROM tiny WHERE v IN (?)").withParam(127).returns((byte)
127).check();
// throw exception
assertQuery("SELECT * FROM tiny WHERE v IN
(?)").withParam("127").returns((byte) 127).check();
{noformat}
{noformat}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Assignment
from VARCHAR to DECIMAL(32767, 16383) can not be performed. Dynamic parameter
requires adding explicit type cast
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22604) OOM caught internally in H2 doesn't call failure handler
[ https://issues.apache.org/jira/browse/IGNITE-22604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861139#comment-17861139 ] Evgeny Stanilovsky commented on IGNITE-22604: - [~amashenkov] can you make a review plz? > OOM caught internally in H2 doesn't call failure handler > > > Key: IGNITE-22604 > URL: https://issues.apache.org/jira/browse/IGNITE-22604 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.16 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > > OOM leads queries brings node into non maintained state also failure handler > is not called in such a case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22444) Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
[
https://issues.apache.org/jira/browse/IGNITE-22444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-22444:
---
Assignee: Evgeny Stanilovsky (was: Pavel Pereslegin)
> Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
> -
>
> Key: IGNITE-22444
> URL: https://issues.apache.org/jira/browse/IGNITE-22444
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to standard:
> {noformat}
> Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
> to the other type, subject to truncation conditions
> {noformat}
> Thus i expect such expressions need to be processed correctly, but it fails:
> {noformat}
> create table tiny(v TINYINT);
> insert into tiny values(127);
> SELECT * FROM tiny WHERE v < '300';
> {noformat}
> {noformat}
> Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
> TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for
> type TINYINT
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
> {noformat}
> Seems such a problem was introduced here [1]
> [1] IGNITE-18662
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22444) Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
[
https://issues.apache.org/jira/browse/IGNITE-22444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22444:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
> -
>
> Key: IGNITE-22444
> URL: https://issues.apache.org/jira/browse/IGNITE-22444
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to standard:
> {noformat}
> Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
> to the other type, subject to truncation conditions
> {noformat}
> Thus i expect such expressions need to be processed correctly, but it fails:
> {noformat}
> create table tiny(v TINYINT);
> insert into tiny values(127);
> SELECT * FROM tiny WHERE v < '300';
> {noformat}
> {noformat}
> Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
> TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for
> type TINYINT
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
> {noformat}
> Seems such a problem was introduced here [1]
> [1] IGNITE-18662
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22604) OOM caught internally in H2 doesn't call failure handler
Evgeny Stanilovsky created IGNITE-22604: --- Summary: OOM caught internally in H2 doesn't call failure handler Key: IGNITE-22604 URL: https://issues.apache.org/jira/browse/IGNITE-22604 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.16 Reporter: Evgeny Stanilovsky Assignee: Evgeny Stanilovsky OOM leads queries brings node into non maintained state also failure handler is not called in such a case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22578) Sql. Extend test coverage for numeric to/from decimal cast with overflow
[ https://issues.apache.org/jira/browse/IGNITE-22578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860349#comment-17860349 ] Evgeny Stanilovsky commented on IGNITE-22578: - [~mzhuravkov] can you make a review plz ? > Sql. Extend test coverage for numeric to/from decimal cast with overflow > > > Key: IGNITE-22578 > URL: https://issues.apache.org/jira/browse/IGNITE-22578 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > After [1] was implemented seems there are some cases still not covered with > tests. Need to improve it. > [1] https://issues.apache.org/jira/browse/IGNITE-18662 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22578) Sql. Extend test coverage for numeric to/from decimal cast with overflow
[ https://issues.apache.org/jira/browse/IGNITE-22578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-22578: --- Assignee: Evgeny Stanilovsky > Sql. Extend test coverage for numeric to/from decimal cast with overflow > > > Key: IGNITE-22578 > URL: https://issues.apache.org/jira/browse/IGNITE-22578 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > After [1] was implemented seems there are some cases still not covered with > tests. Need to improve it. > [1] https://issues.apache.org/jira/browse/IGNITE-18662 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22578) Sql. Extend test coverage for numeric to/from decimal cast with overflow
[ https://issues.apache.org/jira/browse/IGNITE-22578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-22578: Summary: Sql. Extend test coverage for numeric to/from decimal cast with overflow (was: Extend test coverage for numeric to/from decimal cast with overflow) > Sql. Extend test coverage for numeric to/from decimal cast with overflow > > > Key: IGNITE-22578 > URL: https://issues.apache.org/jira/browse/IGNITE-22578 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > After [1] was implemented seems there are some cases still not covered with > tests. Need to improve it. > [1] https://issues.apache.org/jira/browse/IGNITE-18662 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22578) Extend test coverage for numeric to/from decimal cast with overflow
Evgeny Stanilovsky created IGNITE-22578: --- Summary: Extend test coverage for numeric to/from decimal cast with overflow Key: IGNITE-22578 URL: https://issues.apache.org/jira/browse/IGNITE-22578 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky After [1] was implemented seems there are some cases still not covered with tests. Need to improve it. [1] https://issues.apache.org/jira/browse/IGNITE-18662 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22444) Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
[
https://issues.apache.org/jira/browse/IGNITE-22444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860072#comment-17860072
]
Evgeny Stanilovsky commented on IGNITE-22444:
-
Seems need to fix it here : IgniteTypeCoercion#doBinaryComparisonCoercion,
IgniteTypeCoercion#commonTypeForBinaryComparison and return more wide numeric
type.
> Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
> -
>
> Key: IGNITE-22444
> URL: https://issues.apache.org/jira/browse/IGNITE-22444
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to standard:
> {noformat}
> Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
> to the other type, subject to truncation conditions
> {noformat}
> Thus i expect such expressions need to be processed correctly, but it fails:
> {noformat}
> create table tiny(v TINYINT);
> insert into tiny values(127);
> SELECT * FROM tiny WHERE v < '300';
> {noformat}
> {noformat}
> Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
> TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for
> type TINYINT
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
> {noformat}
> Seems such a problem was introduced here [1]
> [1] IGNITE-18662
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22444) Sql. Assign CHARACTER or CHARACTER VARYING to the other type.
Evgeny Stanilovsky created IGNITE-22444:
---
Summary: Sql. Assign CHARACTER or CHARACTER VARYING to the other
type.
Key: IGNITE-22444
URL: https://issues.apache.org/jira/browse/IGNITE-22444
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
According to standard:
{noformat}
Values of either the CHARACTER or CHARACTER VARYING data type can be assigned
to the other type, subject to truncation conditions
{noformat}
Thus i expect such expressions need to be processed correctly, but it fails:
{noformat}
create table tiny(v TINYINT);
insert into tiny values(127);
SELECT * FROM tiny WHERE v < '300';
{noformat}
{noformat}
Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-5
TraceId:cfce3f69-606e-482b-b267-260f8569df62 Value '300' out of range for type
TINYINT
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.literalCanFitType(IgniteSqlValidator.java:714)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.checkTypesInteroperability(IgniteSqlValidator.java:680)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.deriveType(IgniteSqlValidator.java:550)
{noformat}
Seems such a problem was introduced here [1]
[1] IGNITE-18662
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-21960) Extend test coverage for SQL E061-07(Basic predicates and search conditions. Quantified comparison predicate)
[ https://issues.apache.org/jira/browse/IGNITE-21960 ] Evgeny Stanilovsky deleted comment on IGNITE-21960: - was (Author: zstan): [~jooger] i wonder why such "Is a clone of" is linked here .. > Extend test coverage for SQL E061-07(Basic predicates and search conditions. > Quantified comparison predicate) > - > > Key: IGNITE-21960 > URL: https://issues.apache.org/jira/browse/IGNITE-21960 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Test coverage for SQL E061-07(Basic predicates and search conditions. > Quantified comparison predicate) is poor. > Let's increase the test coverage. > ref - > modules/runner/src/integrationTest/sql/subquery/scalar/test_correlated_aggregate_subquery.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21958) Extend test coverage for SQL E021-11(POSITION function)
[ https://issues.apache.org/jira/browse/IGNITE-21958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853098#comment-17853098 ] Evgeny Stanilovsky commented on IGNITE-21958: - [~mzhuravkov] don`t forget to update appropriate doc > Extend test coverage for SQL E021-11(POSITION function) > --- > > Key: IGNITE-21958 > URL: https://issues.apache.org/jira/browse/IGNITE-21958 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Test coverage for SQL E021-11 (POSITION function) is poor. > Let's increase the test coverage. > ref - > modules/runner/src/integrationTest/sql/function/string/test_position.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21967) Extend test coverage for SQL E091-06(Set functions. ALL quantifier)
[ https://issues.apache.org/jira/browse/IGNITE-21967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky resolved IGNITE-21967. - Fix Version/s: 3.0.0-beta2 Resolution: Fixed [~mzhuravkov] thanks, merged, don`t forget to fill appropriate documentation > Extend test coverage for SQL E091-06(Set functions. ALL quantifier) > --- > > Key: IGNITE-21967 > URL: https://issues.apache.org/jira/browse/IGNITE-21967 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Test coverage for SQL E091-06(Set functions. ALL quantifier) is poor. > Let's increase the test coverage. > > ref - modules/runner/src/integrationTest/sql/sqlite/aggregates/agg4.test_slow -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21957) Extend test coverage for SQL E021-10 (Character string types. Implicit casting among the character string types)
[ https://issues.apache.org/jira/browse/IGNITE-21957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21957: --- Assignee: Evgeny Stanilovsky > Extend test coverage for SQL E021-10 (Character string types. Implicit > casting among the character string types) > > > Key: IGNITE-21957 > URL: https://issues.apache.org/jira/browse/IGNITE-21957 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL E021-10 (Character string types. Implicit casting among > the character string types) is poor. > Let's increase the test coverage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21975) Extend test coverage for SQL F302-01(INTERSECT table operator. INTERSECT DISTINCT table operator)
[ https://issues.apache.org/jira/browse/IGNITE-21975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-21975: Affects Version/s: 3.0.0-beta1 > Extend test coverage for SQL F302-01(INTERSECT table operator. INTERSECT > DISTINCT table operator) > - > > Key: IGNITE-21975 > URL: https://issues.apache.org/jira/browse/IGNITE-21975 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Test coverage for SQL F302-01(INTERSECT table operator. INTERSECT DISTINCT > table operator) is poor. > Let's increase the test coverage. > ref - test/sql/subquery/scalar/test_complex_correlated_subquery.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21243) SQL. Bump calcite version to 1.37
[ https://issues.apache.org/jira/browse/IGNITE-21243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-21243: Description: Although calcite 1.37 ver is not resolved, there are couple of issues [1][2] resolved under calcite activity but still mentioned in code under ignite issues activity. The goal of this issue is to check all places where this issue is mentioned and make appropriate fix also bump calcite ver when it become ready. Remove all stuff fixed in [3] and workaround in [4] seems it need to be fixed in new avatica. [1] https://issues.apache.org/jira/browse/IGNITE-21208 [2] https://issues.apache.org/jira/browse/IGNITE-21210 [3] https://issues.apache.org/jira/browse/IGNITE-20809 [4] https://issues.apache.org/jira/browse/IGNITE-15623 was: Although calcite 1.37 ver is not resolved, there are couple of issues [1][2] resolved under calcite activity but still mentioned in code under ignite issues activity. The goal of this issue is to check all places where this issue is mentioned and make appropriate fix also bump calcite ver when it become ready. Remove all stuff fixed in [3] [1] https://issues.apache.org/jira/browse/IGNITE-21208 [2] https://issues.apache.org/jira/browse/IGNITE-21210 [3] https://issues.apache.org/jira/browse/IGNITE-20809 > SQL. Bump calcite version to 1.37 > - > > Key: IGNITE-21243 > URL: https://issues.apache.org/jira/browse/IGNITE-21243 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Although calcite 1.37 ver is not resolved, there are couple of issues [1][2] > resolved under calcite activity but still mentioned in code under ignite > issues activity. The goal of this issue is to check all places where this > issue is mentioned and make appropriate fix also bump calcite ver when it > become ready. Remove all stuff fixed in [3] and workaround in [4] seems it > need to be fixed in new avatica. > [1] https://issues.apache.org/jira/browse/IGNITE-21208 > [2] https://issues.apache.org/jira/browse/IGNITE-21210 > [3] https://issues.apache.org/jira/browse/IGNITE-20809 > [4] https://issues.apache.org/jira/browse/IGNITE-15623 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21960) Extend test coverage for SQL E061-07(Basic predicates and search conditions. Quantified comparison predicate)
[ https://issues.apache.org/jira/browse/IGNITE-21960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852307#comment-17852307 ] Evgeny Stanilovsky commented on IGNITE-21960: - [~jooger] i wonder why such "Is a clone of" is linked here .. > Extend test coverage for SQL E061-07(Basic predicates and search conditions. > Quantified comparison predicate) > - > > Key: IGNITE-21960 > URL: https://issues.apache.org/jira/browse/IGNITE-21960 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL E061-07(Basic predicates and search conditions. > Quantified comparison predicate) is poor. > Let's increase the test coverage. > ref - > modules/runner/src/integrationTest/sql/subquery/scalar/test_correlated_aggregate_subquery.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22405) Sql. Implement log10 function based on java Math.log10 implementation
Evgeny Stanilovsky created IGNITE-22405: --- Summary: Sql. Implement log10 function based on java Math.log10 implementation Key: IGNITE-22405 URL: https://issues.apache.org/jira/browse/IGNITE-22405 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Now log10 implemented as ln(N)/ln(10) this lead to : log10(0.1) == *-0.989*(in period) but expected: *-1* here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21960) Extend test coverage for SQL E061-07(Basic predicates and search conditions. Quantified comparison predicate)
[ https://issues.apache.org/jira/browse/IGNITE-21960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21960: --- Assignee: Evgeny Stanilovsky > Extend test coverage for SQL E061-07(Basic predicates and search conditions. > Quantified comparison predicate) > - > > Key: IGNITE-21960 > URL: https://issues.apache.org/jira/browse/IGNITE-21960 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL E061-07(Basic predicates and search conditions. > Quantified comparison predicate) is poor. > Let's increase the test coverage. > ref - > modules/runner/src/integrationTest/sql/subquery/scalar/test_correlated_aggregate_subquery.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21985) Extend test coverage for SQL T624(Common logarithm functions)
[ https://issues.apache.org/jira/browse/IGNITE-21985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21985: --- Assignee: Evgeny Stanilovsky > Extend test coverage for SQL T624(Common logarithm functions) > - > > Key: IGNITE-21985 > URL: https://issues.apache.org/jira/browse/IGNITE-21985 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T624(Common logarithm functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19307) Sql. Set operations: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849900#comment-17849900
]
Evgeny Stanilovsky commented on IGNITE-19307:
-
[~mzhuravkov] if it no longer relevant - probably it can be closed ?
> Sql. Set operations: Conversion to relational algebra failed to preserve
> datatypes.
> ---
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query fails with "Conversion to relational algebra failed to
> preserve datatypes"
> {code:java}
> @Test
> public void test() {
>sql("CREATE TABLE tt (id integer primary key, test_key integer)");
>sql("INSERT INTO tt VALUES(1, 100)");
>assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
> }
> {code}
> Although the same expression with literal works as expected:
> {code:java}
> @Test
> public void test2() {
>assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
> converted type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[true])
> LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
> IgniteLogicalTableScan(table=[[PUBLIC, TT]])
> LogicalValues(tuples=[[{ _UTF-8'1000' }]])
> {code}
> When both side of set operation are columns query also works:
> {code:java}
> @Test
> public void test3() {
> sql("CREATE TABLE tt (id integer primary key, test_key integer)");
> sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
> sql("INSERT INTO tt VALUES(1, 100)");
> sql("INSERT INTO ttt VALUES(1, '200')");
> assertQuery("SELECT test_key FROM tt UNION ALL SELECT test_key FROM
> ttt").check();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22350) Sql. Datetime functions ignore the precision.
[
https://issues.apache.org/jira/browse/IGNITE-22350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22350:
Description:
According to *6.36 *:
{noformat}
If specified, and respectively determine
the precision of
the time or timestamp value returned.
{noformat}
the same for :
CURRENT_TIME
LOCALTIME
CURRENT_TIMESTAMP
LOCALTIMESTAMP
for now SELECT LOCALTIME(2) returns: 08:57:46.*643*
starting point : ItFunctionsTest#testCurrentDateTimeTimeStamp
was:
According to *6.36 *:
{noformat}
If specified, and respectively determine
the precision of
the time or timestamp value returned.
{noformat}
the same for :
CURRENT_TIME
LOCALTIME
CURRENT_TIMESTAMP
LOCALTIMESTAMP
starting point : ItFunctionsTest#testCurrentDateTimeTimeStamp
> Sql. Datetime functions ignore the precision.
> -
>
> Key: IGNITE-22350
> URL: https://issues.apache.org/jira/browse/IGNITE-22350
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to *6.36 *:
> {noformat}
> If specified, and respectively
> determine the precision of
> the time or timestamp value returned.
> {noformat}
> the same for :
> CURRENT_TIME
> LOCALTIME
> CURRENT_TIMESTAMP
> LOCALTIMESTAMP
> for now SELECT LOCALTIME(2) returns: 08:57:46.*643*
> starting point : ItFunctionsTest#testCurrentDateTimeTimeStamp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22350) Sql. Datetime functions ignore the precision.
Evgeny Stanilovsky created IGNITE-22350:
---
Summary: Sql. Datetime functions ignore the precision.
Key: IGNITE-22350
URL: https://issues.apache.org/jira/browse/IGNITE-22350
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
According to *6.36 *:
{noformat}
If specified, and respectively determine
the precision of
the time or timestamp value returned.
{noformat}
the same for :
CURRENT_TIME
LOCALTIME
CURRENT_TIMESTAMP
LOCALTIMESTAMP
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22350) Sql. Datetime functions ignore the precision.
[
https://issues.apache.org/jira/browse/IGNITE-22350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22350:
Description:
According to *6.36 *:
{noformat}
If specified, and respectively determine
the precision of
the time or timestamp value returned.
{noformat}
the same for :
CURRENT_TIME
LOCALTIME
CURRENT_TIMESTAMP
LOCALTIMESTAMP
starting point : ItFunctionsTest#testCurrentDateTimeTimeStamp
was:
According to *6.36 *:
{noformat}
If specified, and respectively determine
the precision of
the time or timestamp value returned.
{noformat}
the same for :
CURRENT_TIME
LOCALTIME
CURRENT_TIMESTAMP
LOCALTIMESTAMP
> Sql. Datetime functions ignore the precision.
> -
>
> Key: IGNITE-22350
> URL: https://issues.apache.org/jira/browse/IGNITE-22350
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to *6.36 *:
> {noformat}
> If specified, and respectively
> determine the precision of
> the time or timestamp value returned.
> {noformat}
> the same for :
> CURRENT_TIME
> LOCALTIME
> CURRENT_TIMESTAMP
> LOCALTIMESTAMP
> starting point : ItFunctionsTest#testCurrentDateTimeTimeStamp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22345) Sql. Support datetime value expression with appropriate time zone.
[
https://issues.apache.org/jira/browse/IGNITE-22345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22345:
Description:
According to standard, Feature F411:
_6.35 _
we need to support syntax like :
{noformat}
SELECT LOCALTIMESTAMP|LOCALTIME AT TIME ZONE 'America/New_York';
SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'America/New_York';
SELECT CURRENT_DATE AT TIME ZONE 'America/New_York';
{noformat}
was:
According to standard :
_6.35 _
we need to support syntax like :
{noformat}
SELECT LOCALTIMESTAMP|LOCALTIME AT TIME ZONE 'America/New_York';
SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'America/New_York';
SELECT CURRENT_DATE AT TIME ZONE 'America/New_York';
{noformat}
> Sql. Support datetime value expression with appropriate time zone.
> --
>
> Key: IGNITE-22345
> URL: https://issues.apache.org/jira/browse/IGNITE-22345
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to standard, Feature F411:
> _6.35 _
> we need to support syntax like :
> {noformat}
> SELECT LOCALTIMESTAMP|LOCALTIME AT TIME ZONE 'America/New_York';
> SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'America/New_York';
> SELECT CURRENT_DATE AT TIME ZONE 'America/New_York';
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22347) Sql. WITH TIME ZONE syntax support.
[
https://issues.apache.org/jira/browse/IGNITE-22347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22347:
Description:
According to standard:
_6.19 _
Feature F411, syntax like :
{noformat}
If TP is specified, then LOCALTIME(TP) is equivalent to:
CAST (CURRENT_TIME(TP) AS TIME(TP) WITHOUT TIME ZONE)
{noformat}
need to be supported, seems it fixed in calcite 1.37, issue [1].
We need to check it after calcite ver update and append new tests
[1] https://issues.apache.org/jira/browse/CALCITE-6138
was:
According to standard:
_6.19 _
syntax like :
{noformat}
If TP is specified, then LOCALTIME(TP) is equivalent to:
CAST (CURRENT_TIME(TP) AS TIME(TP) WITHOUT TIME ZONE)
{noformat}
need to be supported, seems it fixed in calcite 1.37, issue [1].
We need to check it after calcite ver update and append new tests
[1] https://issues.apache.org/jira/browse/CALCITE-6138
> Sql. WITH TIME ZONE syntax support.
> ---
>
> Key: IGNITE-22347
> URL: https://issues.apache.org/jira/browse/IGNITE-22347
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to standard:
> _6.19 _
> Feature F411, syntax like :
> {noformat}
> If TP is specified, then LOCALTIME(TP) is equivalent to:
> CAST (CURRENT_TIME(TP) AS TIME(TP) WITHOUT TIME ZONE)
> {noformat}
> need to be supported, seems it fixed in calcite 1.37, issue [1].
> We need to check it after calcite ver update and append new tests
> [1] https://issues.apache.org/jira/browse/CALCITE-6138
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
