[jira] [Updated] (IGNITE-23299) Sql. Fix invalid inflight transaction tracking.
[ https://issues.apache.org/jira/browse/IGNITE-23299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-23299: -- Fix Version/s: 3.0 > Sql. Fix invalid inflight transaction tracking. > --- > > Key: IGNITE-23299 > URL: https://issues.apache.org/jira/browse/IGNITE-23299 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite3 > Fix For: 3.0 > > > PartitionScanSubscription may unexpectedly trigger > `inflightBatchRequestTracker.onRequestEnd()` twice in case of batch > processing error. in `scanBatch` method. > The first call is expected and happens on happy-path after getting a > successful response. > But if batch processing failed with error (e.g. `subscriber::onNext`), then > we get into unhappy-path and trigger > `inflightBatchRequestTracker.onRequestEnd()` once again, which violates the > contract. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23299) Sql. Fix invalid inflight transaction tracking.
[ https://issues.apache.org/jira/browse/IGNITE-23299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-23299: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Fix invalid inflight transaction tracking. > --- > > Key: IGNITE-23299 > URL: https://issues.apache.org/jira/browse/IGNITE-23299 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > PartitionScanSubscription may unexpectedly trigger > `inflightBatchRequestTracker.onRequestEnd()` twice in case of batch > processing error. in `scanBatch` method. > The first call is expected and happens on happy-path after getting a > successful response. > But if batch processing failed with error (e.g. `subscriber::onNext`), then > we get into unhappy-path and trigger > `inflightBatchRequestTracker.onRequestEnd()` once again, which violates the > contract. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23299) Sql. Fix invalid inflight transaction tracking.
[ https://issues.apache.org/jira/browse/IGNITE-23299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-23299: - Assignee: Andrey Mashenkov > Sql. Fix invalid inflight transaction tracking. > --- > > Key: IGNITE-23299 > URL: https://issues.apache.org/jira/browse/IGNITE-23299 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite3 > > PartitionScanSubscription may unexpectedly trigger > `inflightBatchRequestTracker.onRequestEnd()` twice in case of batch > processing error. in `scanBatch` method. > The first call is expected and happens on happy-path after getting a > successful response. > But if batch processing failed with error (e.g. `subscriber::onNext`), then > we get into unhappy-path and trigger > `inflightBatchRequestTracker.onRequestEnd()` once again, which violates the > contract. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23299) Sql. Fix invalid inflight transaction tracking.
[ https://issues.apache.org/jira/browse/IGNITE-23299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-23299: -- Issue Type: Bug (was: Test) > Sql. Fix invalid inflight transaction tracking. > --- > > Key: IGNITE-23299 > URL: https://issues.apache.org/jira/browse/IGNITE-23299 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite3 > > PartitionScanSubscription may unexpectedly trigger > `inflightBatchRequestTracker.onRequestEnd()` twice in case of batch > processing error. in `scanBatch` method. > The first call is expected and happens on happy-path after getting a > successful response. > But if batch processing failed with error (e.g. `subscriber::onNext`), then > we get into unhappy-path and trigger > `inflightBatchRequestTracker.onRequestEnd()` once again, which violates the > contract. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23299) Sql. Fix invalid inflight transaction tracking.
Andrey Mashenkov created IGNITE-23299: - Summary: Sql. Fix invalid inflight transaction tracking. Key: IGNITE-23299 URL: https://issues.apache.org/jira/browse/IGNITE-23299 Project: Ignite Issue Type: Test Components: sql Reporter: Andrey Mashenkov PartitionScanSubscription may unexpectedly trigger `inflightBatchRequestTracker.onRequestEnd()` twice in case of batch processing error. in `scanBatch` method. The first call is expected and happens on happy-path after getting a successful response. But if batch processing failed with error (e.g. `subscriber::onNext`), then we get into unhappy-path and trigger `inflightBatchRequestTracker.onRequestEnd()` once again, which violates the contract. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22988) Sql. Align implementations of average calculation (AVG)
[ https://issues.apache.org/jira/browse/IGNITE-22988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22988: -- Fix Version/s: 3.0 > Sql. Align implementations of average calculation (AVG) > --- > > Key: IGNITE-22988 > URL: https://issues.apache.org/jira/browse/IGNITE-22988 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We have Map/Reduce and Collocated algorithms of implementations for > calculation average values. > At least for the DECIMAL type we have different implementations which can > produce different precision/scale of results and value of results. > We need to do the following: > 1) Check implementations of AVG for all types and align them, including > resolving types of results. > 2) The result type of AVG in the plan and the real result type after > execution should be identical. > Points to start investigate: > # ItAggregatesTest > # AccumulatorsFactory > # IgniteSqlFunctions#decimalDivide > # MapReduceAggregates#createAvgAgg -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22988) Sql. Align implementations of average calculation (AVG)
[ https://issues.apache.org/jira/browse/IGNITE-22988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22988: - Assignee: Andrey Mashenkov > Sql. Align implementations of average calculation (AVG) > --- > > Key: IGNITE-22988 > URL: https://issues.apache.org/jira/browse/IGNITE-22988 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We have Map/Reduce and Collocated algorithms of implementations for > calculation average values. > At least for the DECIMAL type we have different implementations which can > produce different precision/scale of results and value of results. > We need to do the following: > 1) Check implementations of AVG for all types and align them, including > resolving types of results. > 2) The result type of AVG in the plan and the real result type after > execution should be identical. > Points to start investigate: > # ItAggregatesTest > # AccumulatorsFactory > # IgniteSqlFunctions#decimalDivide > # MapReduceAggregates#createAvgAgg -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22988) Sql. Align implementations of average calculation (AVG)
[ https://issues.apache.org/jira/browse/IGNITE-22988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22988: - Assignee: (was: Andrey Mashenkov) > Sql. Align implementations of average calculation (AVG) > --- > > Key: IGNITE-22988 > URL: https://issues.apache.org/jira/browse/IGNITE-22988 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have Map/Reduce and Collocated algorithms of implementations for > calculation average values. > At least for the DECIMAL type we have different implementations which can > produce different precision/scale of results and value of results. > We need to do the following: > 1) Check implementations of AVG for all types and align them, including > resolving types of results. > 2) The result type of AVG in the plan and the real result type after > execution should be identical. > Points to start investigate: > # ItAggregatesTest > # AccumulatorsFactory > # IgniteSqlFunctions#decimalDivide > # MapReduceAggregates#createAvgAgg -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22988) Sql. Align implementations of average calculation (AVG)
[ https://issues.apache.org/jira/browse/IGNITE-22988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22988: - Assignee: Andrey Mashenkov > Sql. Align implementations of average calculation (AVG) > --- > > Key: IGNITE-22988 > URL: https://issues.apache.org/jira/browse/IGNITE-22988 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We have Map/Reduce and Collocated algorithms of implementations for > calculation average values. > At least for the DECIMAL type we have different implementations which can > produce different precision/scale of results and value of results. > We need to do the following: > 1) Check implementations of AVG for all types and align them, including > resolving types of results. > 2) The result type of AVG in the plan and the real result type after > execution should be identical. > Points to start investigate: > # ItAggregatesTest > # AccumulatorsFactory > # IgniteSqlFunctions#decimalDivide > # MapReduceAggregates#createAvgAgg -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-22697) Sql. Comparison on BIGINT cast brings overflow
[
https://issues.apache.org/jira/browse/IGNITE-22697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov closed IGNITE-22697.
-
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> create table tbl(v BIGINT);
> insert into tbl values(9223372036854775807);
> SELECT * FROM tbl WHERE v < 9223372036854775808::DECIMAL(19, 0);
> {noformat}
> will compile into:
> {noformat}
> try {
> final Long input_value = (Long) ctx.rowHandler().get(0, in1);
> final java.math.BigDecimal cast_value = input_value == null ? null :
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal(input_value.longValue(),
> 19, 0);
> out.addField(cast_value == null ? null :
> Boolean.valueOf(org.apache.calcite.runtime.SqlFunctions.lt(cast_value,
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal("-9223372036854775808",
> 19, 0;
> } catch (Exception e) {
> throw new org.apache.ignite.sql.SqlException(
> 262151,
> e);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22697) Sql. Comparison on BIGINT cast brings overflow
[
https://issues.apache.org/jira/browse/IGNITE-22697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov resolved IGNITE-22697.
---
Resolution: Won't Fix
Can't reproduce.
Was fixed in IGNITE-22817
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> create table tbl(v BIGINT);
> insert into tbl values(9223372036854775807);
> SELECT * FROM tbl WHERE v < 9223372036854775808::DECIMAL(19, 0);
> {noformat}
> will compile into:
> {noformat}
> try {
> final Long input_value = (Long) ctx.rowHandler().get(0, in1);
> final java.math.BigDecimal cast_value = input_value == null ? null :
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal(input_value.longValue(),
> 19, 0);
> out.addField(cast_value == null ? null :
> Boolean.valueOf(org.apache.calcite.runtime.SqlFunctions.lt(cast_value,
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal("-9223372036854775808",
> 19, 0;
> } catch (Exception e) {
> throw new org.apache.ignite.sql.SqlException(
> 262151,
> e);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22945) Remove duplicate method from CatalogTableDescriptor
[
https://issues.apache.org/jira/browse/IGNITE-22945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22945:
-
Assignee: Andrey Mashenkov
> Remove duplicate method from CatalogTableDescriptor
> ---
>
> Key: IGNITE-22945
> URL: https://issues.apache.org/jira/browse/IGNITE-22945
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Minor
> Labels: ignite-3, newbie
>
> {{CatalogTableDescriptor}} has two identical methods to get a
> {{CatalogTableColumnDescriptor}} by column name.
> {code:java}
> public CatalogTableColumnDescriptor column(String name)
> public CatalogTableColumnDescriptor columnDescriptor(String columnName)
> {code}
> Need to remove one of them.
> Personally, I prefer to get rid from {{columnDescriptor()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22697) Sql. Comparison on BIGINT cast brings overflow
[
https://issues.apache.org/jira/browse/IGNITE-22697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22697:
-
Assignee: Andrey Mashenkov
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> create table tbl(v BIGINT);
> insert into tbl values(9223372036854775807);
> SELECT * FROM tbl WHERE v < 9223372036854775808::DECIMAL(19, 0);
> {noformat}
> will compile into:
> {noformat}
> try {
> final Long input_value = (Long) ctx.rowHandler().get(0, in1);
> final java.math.BigDecimal cast_value = input_value == null ? null :
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal(input_value.longValue(),
> 19, 0);
> out.addField(cast_value == null ? null :
> Boolean.valueOf(org.apache.calcite.runtime.SqlFunctions.lt(cast_value,
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.toBigDecimal("-9223372036854775808",
> 19, 0;
> } catch (Exception e) {
> throw new org.apache.ignite.sql.SqlException(
> 262151,
> e);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18747) Sql. Provide commands and handlers for alter index name operation
[ https://issues.apache.org/jira/browse/IGNITE-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-18747: - Assignee: Andrey Mashenkov > Sql. Provide commands and handlers for alter index name operation > - > > Key: IGNITE-18747 > URL: https://issues.apache.org/jira/browse/IGNITE-18747 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > After implementing IGNITE-16196 need to provide DDL command and handler to > altering index name, as well as translation to the command from AST > representation. > As a result, we will be able to translate AST to a command (see > DdlSqlToCommandConverter) and execute this command in order to apply changes > to configuration (see DdlCommandHandler) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19066) Sql. Investigate why there is more than one instance of default value placeholder.
[
https://issues.apache.org/jira/browse/IGNITE-19066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874887#comment-17874887
]
Andrey Mashenkov commented on IGNITE-19066:
---
Seems, this ticket is no longer valid after IGNITE-19130.
> Sql. Investigate why there is more than one instance of default value
> placeholder.
> --
>
> Key: IGNITE-19066
> URL: https://issues.apache.org/jira/browse/IGNITE-19066
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Investigate why there is more than value of default value placeholder even
> though Default value placeholder implements readResolve method and it is uses
> java serialization.
> Reproducer:
> Update RexImpTable to use the following code for placeholders.
> {code:java}
> private static class Placeholder {
> static final Object DEFAULT_VALUE = DefaultValuePlaceholder.VALUE;
> static final Object UNSPECIFIED_VALUE =
> UnspecifiedValuePlaceholder.VALUE;
> }
> public static void ensurePlaceholderRemoved(Object value) {
> if (value instanceof DefaultValuePlaceholder && value !=
> Placeholder.DEFAULT_VALUE) {
> throw new AssertionError("Unexpected DEFAULT value placeholder: "
> + value + ". Expected: " + Placeholder.DEFAULT_VALUE);
> }
> }
> private static final class DefaultValuePlaceholder implements
> Serializable {
> private static final DefaultValuePlaceholder VALUE = new
> DefaultValuePlaceholder();
> private static final long serialVersionUID = -978388731876609995L;
> private Object readResolve() {
> return VALUE;
> }
> public String toString() {
> return "DEFAULT#" + hashCode();
> }
> }
> private static final class UnspecifiedValuePlaceholder implements
> Serializable {
> private static final UnspecifiedValuePlaceholder VALUE = new
> UnspecifiedValuePlaceholder();
> private static final long serialVersionUID = 3312208611999510012L;
> private Object readResolve() {
> return VALUE;
> }
> public String toString() {
> return "";
> }
> }
> {code}
> Update IgniteTableImpl convertRow:
> {code:java}
> Object val = hnd.get(colDesc.logicalIndex(), row);
> + if (val != null) {
> + RexImpTable.ensurePlaceholderRemoved(val);
> + }
> {code}
> Error:
> {code:java}
> Caused by: java.lang.AssertionError: Unexpected DEFAULT value placeholder:
> DEFAULT#238068340. Expected: DEFAULT#1599919888
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable.ensurePlaceholderRemoved(RexImpTable.java:2588)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.convertRow(IgniteTableImpl.java:514)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.insertAll(IgniteTableImpl.java:390)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:218)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:187)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:160)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushUnordered(Inbox.java:333)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19089) Sql. ItIgniteNodeRestartTest::testTwoNodesRestartReverse hangs at TableImpl.pkId(TableImpl.java:127)
[
https://issues.apache.org/jira/browse/IGNITE-19089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-19089:
--
Labels: ignite-3 (was: calcite3-required ignite-3)
> Sql. ItIgniteNodeRestartTest::testTwoNodesRestartReverse hangs at
> TableImpl.pkId(TableImpl.java:127)
>
>
> Key: IGNITE-19089
> URL: https://issues.apache.org/jira/browse/IGNITE-19089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> ItIgniteNodeRestartTest::testTwoNodesRestartReverse fails to complete.
> {code:java}
> Hangs at org.apache.ignite.internal.table.TableImpl.pkId(TableImpl.java:127)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19089) Sql. ItIgniteNodeRestartTest::testTwoNodesRestartReverse hangs at TableImpl.pkId(TableImpl.java:127)
[
https://issues.apache.org/jira/browse/IGNITE-19089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov resolved IGNITE-19089.
---
Resolution: Won't Fix
The ticket refers to a non-existing part of code, the future was replaced with
a value and the issue with hanging on future just no longer exists.
The test looks stable good on master.
> Sql. ItIgniteNodeRestartTest::testTwoNodesRestartReverse hangs at
> TableImpl.pkId(TableImpl.java:127)
>
>
> Key: IGNITE-19089
> URL: https://issues.apache.org/jira/browse/IGNITE-19089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: calcite3-required, ignite-3
>
> ItIgniteNodeRestartTest::testTwoNodesRestartReverse fails to complete.
> {code:java}
> Hangs at org.apache.ignite.internal.table.TableImpl.pkId(TableImpl.java:127)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22963) Remove fastutils from dependencies of ignite-api
[
https://issues.apache.org/jira/browse/IGNITE-22963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22963:
-
Assignee: Andrey Mashenkov
> Remove fastutils from dependencies of ignite-api
>
>
> Key: IGNITE-22963
> URL: https://issues.apache.org/jira/browse/IGNITE-22963
> Project: Ignite
> Issue Type: Improvement
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> An {{ignite-api}} module must be free of 3rd-party dependencies required in
> runtime. At this moment this is violated by {{fastutil}} collections:
> {code:java}
> // modules/api/build.gradle
> dependencies {
> <...>
> implementation libs.fastutil.core
> {code}
> It is only used by {{ErrorGroup}} class to register codes - this is init-only
> code, performance is not a concern.
> Let's clean up dependencies list of {{ignite-api}} module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22861) Sql. Calculation for mapOnBackups parameter erased.
[
https://issues.apache.org/jira/browse/IGNITE-22861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-22861:
--
Fix Version/s: 3.0.0-beta2
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Created] (IGNITE-22969) Sql. Replanning query on unstable topology
Andrey Mashenkov created IGNITE-22969: - Summary: Sql. Replanning query on unstable topology Key: IGNITE-22969 URL: https://issues.apache.org/jira/browse/IGNITE-22969 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov ExecutionTargetFactory implementations calculates execution nodes for the query fragments and then effectively finds colocated fragments operating with nodes order (int) instead of nodes ids (string). To do that, we need to know all available nodes. So, we read LogicalTopology before mapping query fragments. Then we read assignments for all the tables used in the query. On unstable topology, we may observe a node in assignment, which wasn't part of LogicalTopology at the previous step. E.g. the missed node can be just failed node or can be just joined node. In IGNITE-22861 was decide to ignore unknown nodes. So, possible solution * left "as is" * throw an exception when unknown node was found, then restart query planning phase * add a relation between LogicalTopology and partition Assignments to avoid this case * use single source (e.g. assignments) for getting cluster nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871609#comment-17871609
]
Andrey Mashenkov edited comment on IGNITE-22722 at 8/9/24 10:13 AM:
{{AssignmentsPlacementDriver.getAssignments}} javadoc says the method returns a
future, which may completes with {{`null`}} if no assignment found for given
replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
was (Author: amashenkov):
{{`AssignmentsPlacementDriver.getAssignments`}} javadoc says the method returns
a future, which may completes with {{`null`}} if no assignment found for given
replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871609#comment-17871609
]
Andrey Mashenkov edited comment on IGNITE-22722 at 8/9/24 10:12 AM:
{{`AssignmentsPlacementDriver.getAssignments`}} javadoc says the method returns
a future, which may completes with {{`null`}} if no assignment found for given
replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
was (Author: amashenkov):
{{AssignmentsPlacementDriver.getAssignments }}javadoc says the method returns a
future, which may completes with {{{}`null{}}}` if no assignment found for
given replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871609#comment-17871609
]
Andrey Mashenkov edited comment on IGNITE-22722 at 8/9/24 10:12 AM:
{{AssignmentsPlacementDriver.getAssignments }}javadoc says the method returns a
future, which may completes with {{{}`null{}}}` if no assignment found for
given replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
was (Author: amashenkov):
{{AssignmentsPlacementDriver.getAssignments }}javadoc says the method returns a
future, which may completes with `{{{}null{}}}` if no assignment found for
given replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872291#comment-17872291
]
Andrey Mashenkov commented on IGNITE-22722:
---
I've preserved original behavior. The new method may return a list with
`{{{}null{}}}` element which assignment wasn't found for.
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22861) Sql. Calculation for mapOnBackups parameter erased.
[
https://issues.apache.org/jira/browse/IGNITE-22861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871967#comment-17871967
]
Andrey Mashenkov commented on IGNITE-22861:
---
We need a refactoring.
For now, we read a LogicalTopology, then read assignments for fragment mapping.
We use LogicalTopology for both: ensure cached mapping is valid and enumerate
nodes, to operate node order (int) instead of consistentId (String) for
collocation calculation.
The issue here, the logical topology may be changed in between, which lead to
an error when we try to resolve node order from assignment against outdated
topology.
Also, assignments has no connection with logical topology. So, we have to
rethink this part.
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-22861) Sql. Calculation for mapOnBackups parameter erased.
[
https://issues.apache.org/jira/browse/IGNITE-22861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871951#comment-17871951
]
Andrey Mashenkov commented on IGNITE-22861:
---
The fix makes test failed:
{{ItIgniteNodeRestartTest.testQueryCorrectnessAfterNodeRestart}}
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Assigned] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22722:
-
Assignee: Andrey Mashenkov
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22861) Sql. Calculation for mapOnBackups parameter erased.
[
https://issues.apache.org/jira/browse/IGNITE-22861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22861:
-
Assignee: Andrey Mashenkov
> 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
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> 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-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871609#comment-17871609
]
Andrey Mashenkov commented on IGNITE-22722:
---
{{AssignmentsPlacementDriver.getAssignments }}javadoc says the method returns a
future, which may completes with `{{{}null{}}}` if no assignment found for
given replication group id.
I guess, the method should never ignore missed assignment, and should either
return a `null` if any assignment was missed or failed with error.
What is expected behavior for this new method?
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22722:
-
Assignee: (was: Andrey Mashenkov)
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22722) Add the ability to get assignments for a list of replication groups at once.
[
https://issues.apache.org/jira/browse/IGNITE-22722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22722:
-
Assignee: Andrey Mashenkov
> Add the ability to get assignments for a list of replication groups at once.
>
>
> Key: IGNITE-22722
> URL: https://issues.apache.org/jira/browse/IGNITE-22722
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> At the moment, it is not possible to get assignments for several replication
> groups at once.
> {{AssignmentsPlacementDriver}} has the following method only to get
> assignments.
> {code:java}
> CompletableFuture getAssignments(ReplicationGroupId
> replicationGroupId, HybridTimestamp clusterTimeToAwait);
> {code}
> But sometimes you need to get assignments for a list of several replication
> groups, so it would be nice to have a separate method for this, something
> like the following:
> {code:java}
> CompletableFuture>
> getAssignments(List replicationGroupId, HybridTimestamp
> clusterTimeToAwait);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22681) Get rid of Session mention in AI3
[ https://issues.apache.org/jira/browse/IGNITE-22681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22681: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Get rid of Session mention in AI3 > - > > Key: IGNITE-22681 > URL: https://issues.apache.org/jira/browse/IGNITE-22681 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > After `Session` was removed from AI3 code (IGNITE-21669) we still have a few > place that mention. Let's find all the places and clean it up. For example > such places: > docs/_docs/developers-guide/clients/java.adoc > docs/_docs/quick-start/embedded-mode.adoc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22681) Get rid of Session mention in AI3
[ https://issues.apache.org/jira/browse/IGNITE-22681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22681: -- Fix Version/s: 3.0.0-beta2 > Get rid of Session mention in AI3 > - > > Key: IGNITE-22681 > URL: https://issues.apache.org/jira/browse/IGNITE-22681 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > After `Session` was removed from AI3 code (IGNITE-21669) we still have a few > place that mention. Let's find all the places and clean it up. For example > such places: > docs/_docs/developers-guide/clients/java.adoc > docs/_docs/quick-start/embedded-mode.adoc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22681) Get rid of Session mention in AI3
[ https://issues.apache.org/jira/browse/IGNITE-22681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22681: - Assignee: Andrey Mashenkov > Get rid of Session mention in AI3 > - > > Key: IGNITE-22681 > URL: https://issues.apache.org/jira/browse/IGNITE-22681 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > After `Session` was removed from AI3 code (IGNITE-21669) we still have a few > place that mention. Let's find all the places and clean it up. For example > such places: > docs/_docs/developers-guide/clients/java.adoc > docs/_docs/quick-start/embedded-mode.adoc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22303) Sql. Retry operation when plan gets outdated by the time of execution
[ https://issues.apache.org/jira/browse/IGNITE-22303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22303: - Assignee: (was: Andrey Mashenkov) > Sql. Retry operation when plan gets outdated by the time of execution > - > > Key: IGNITE-22303 > URL: https://issues.apache.org/jira/browse/IGNITE-22303 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In IGNITE-22263 start of the transaction was moved to execution phase. This > may cause situation, when plan gets outdated by the time of execution. Such > cases should be detected and handled properly (by retrying operation one more > time). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22611) SQL. Statement should not extends AutoClosable
[ https://issues.apache.org/jira/browse/IGNITE-22611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22611: - Assignee: Andrey Mashenkov > SQL. Statement should not extends AutoClosable > --- > > Key: IGNITE-22611 > URL: https://issues.apache.org/jira/browse/IGNITE-22611 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Statement doesn't hold any resources, but AutoClosable interface assume using > try-with-resources. > A try-with-resources block forces user to catch the exception, because of > `close()` method signature. > However, all of this make no sense, single implementation has empty `close()` > method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22611) SQL. Statement should not extends AutoClosable
Andrey Mashenkov created IGNITE-22611: - Summary: SQL. Statement should not extends AutoClosable Key: IGNITE-22611 URL: https://issues.apache.org/jira/browse/IGNITE-22611 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov Fix For: 3.0.0-beta2 Statement doesn't hold any resources, but AutoClosable interface assume using try-with-resources. A try-with-resources block forces user to catch the exception, because of `close()` method signature. However, all of this make no sense, single implementation has empty `close()` method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22303) Sql. Retry operation when plan gets outdated by the time of execution
[ https://issues.apache.org/jira/browse/IGNITE-22303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22303: - Assignee: Andrey Mashenkov > Sql. Retry operation when plan gets outdated by the time of execution > - > > Key: IGNITE-22303 > URL: https://issues.apache.org/jira/browse/IGNITE-22303 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In IGNITE-22263 start of the transaction was moved to execution phase. This > may cause situation, when plan gets outdated by the time of execution. Such > cases should be detected and handled properly (by retrying operation one more > time). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20503) Sql. Support big clusters by mapping service
[ https://issues.apache.org/jira/browse/IGNITE-20503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856710#comment-17856710 ] Andrey Mashenkov commented on IGNITE-20503: --- I'd suggest using more effective bitmap implementations like RoaringBitmap or Tree-encoded bitmap or else. Typical query execution flow is running fragments on data nodes and fetch the data to a single node. As I understand, mostly used execution targets will be OneOf (of a single node) and Partitioned (a bunch of very small node sets, comparing to cluster size). In most cases, I'd expect a BitMap will contains either a single 1-bit or have high clustering factor (i.e. how probable 1-bit will be followed by another 1-bit). In these cases, suggested implementations are very effective in both aspects: memory and performance. > Sql. Support big clusters by mapping service > > > Key: IGNITE-20503 > URL: https://issues.apache.org/jira/browse/IGNITE-20503 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > After refactoring made in IGNITE-20502, only clusters up to 64 nodes > supported by MappingService. > Let's implement one more ExecutionTargetFactory to support clusters of > arbitrary size. See SmallClusterFactory and other classes in the same package > for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20503) Sql. Support big clusters by mapping service
[ https://issues.apache.org/jira/browse/IGNITE-20503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20503: -- Fix Version/s: 3.0.0-beta2 > Sql. Support big clusters by mapping service > > > Key: IGNITE-20503 > URL: https://issues.apache.org/jira/browse/IGNITE-20503 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > After refactoring made in IGNITE-20502, only clusters up to 64 nodes > supported by MappingService. > Let's implement one more ExecutionTargetFactory to support clusters of > arbitrary size. See SmallClusterFactory and other classes in the same package > for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20503) Sql. Support big clusters by mapping service
[ https://issues.apache.org/jira/browse/IGNITE-20503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-20503: - Assignee: Andrey Mashenkov > Sql. Support big clusters by mapping service > > > Key: IGNITE-20503 > URL: https://issues.apache.org/jira/browse/IGNITE-20503 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > After refactoring made in IGNITE-20502, only clusters up to 64 nodes > supported by MappingService. > Let's implement one more ExecutionTargetFactory to support clusters of > arbitrary size. See SmallClusterFactory and other classes in the same package > for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22270) MarshallerException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22270: - Assignee: Andrey Mashenkov > MarshallerException uses INTERNAL_ERR code > -- > > Key: IGNITE-22270 > URL: https://issues.apache.org/jira/browse/IGNITE-22270 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > *INTERNAL_ERR* does not make sense for *MarshallerException* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21964) Extend test coverage for SQL E031-01(Identifiers. Delimited identifiers)
[ https://issues.apache.org/jira/browse/IGNITE-21964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21964: - Assignee: Andrey Mashenkov > Extend test coverage for SQL E031-01(Identifiers. Delimited identifiers) > > > Key: IGNITE-21964 > URL: https://issues.apache.org/jira/browse/IGNITE-21964 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL E031-01(Identifiers. Delimited identifiers) is poor. > Let's increase the test coverage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16116) Support user mapping functions
[
https://issues.apache.org/jira/browse/IGNITE-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-16116:
--
Description:
Let's allow users to implement their own strategy of marshaling objects.
The {{Tuple}} interface looks good candidate for representing a row, rather
than exposing any internals to the user.
Suggested method signature for {{org.apache.ignite.table.mapper.Mapper}} class
{code:java}
/**
* Adds a manual functional mapping for an object and a row represented by a
tuple.
*
* @param objectToRow Object to tuple function.
* @param rowToObject Tuple to object function.
* @return {@code this} for chaining.
*/
static Mapper of(Function objectToRow, Function
rowToObject);{code}
was:
Let's allow users to implement their own strategy of marshaling objects.
The {{Tuple}} interface looks good candidate for representing a row, rather
than exposing any internals to the user.
Start point is {{Mapper.of(Function objectToRow, Function
rowToObject)}}.
> Support user mapping functions
> --
>
> Key: IGNITE-16116
> URL: https://issues.apache.org/jira/browse/IGNITE-16116
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> Let's allow users to implement their own strategy of marshaling objects.
> The {{Tuple}} interface looks good candidate for representing a row, rather
> than exposing any internals to the user.
> Suggested method signature for {{org.apache.ignite.table.mapper.Mapper}} class
> {code:java}
> /**
> * Adds a manual functional mapping for an object and a row represented by a
> tuple.
> *
> * @param objectToRow Object to tuple function.
> * @param rowToObject Tuple to object function.
> * @return {@code this} for chaining.
> */
> static Mapper of(Function objectToRow, Function
> rowToObject);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-22393:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Assignee: Andrey Mashenkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22393:
-
Assignee: Andrey Mashenkov
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Assignee: Andrey Mashenkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-22393:
--
Fix Version/s: 3.0.0-beta2
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-22393:
--
Priority: Blocker (was: Major)
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20650) Table API. Field names are not resolved correctly.
[
https://issues.apache.org/jira/browse/IGNITE-20650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-20650:
-
Assignee: Andrey Mashenkov
> Table API. Field names are not resolved correctly.
> --
>
> Key: IGNITE-20650
> URL: https://issues.apache.org/jira/browse/IGNITE-20650
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of Tuple/Record field name is not consistent with
> requirements specified in https://issues.apache.org/jira/browse/IGNITE-16322:
> Field access:
> {code:java}
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteTables tables = ignite.tables();
> sql("CREATE TABLE \"values\" (\"Id\" INTEGER PRIMARY KEY, \"Val\" VARCHAR)");
> sql("INSERT INTO \"values\" VALUES(1, '1')");
> Table table = tables.table("\"values\"");
> RecordView recordView = table.recordView();
> Tuple key = Tuple.create(Map.of("id", 1));
> Tuple record = recordView.get(null, key);
> // Works
> assertNotNull(record);
> // Works
> assertNotNull(record.value("\"Id\""));
> // https://issues.apache.org/jira/browse/IGNITE-16322
> // According to the ticket, the following assertions should not fail:
>
> // Invalid column name: columnName=Id
> assertNotNull(record.value("Id"));
> // Invalid column name: columnName=ID
> assertNotNull(record.value("ID"));
> {code}
> New tuple:
> {code:java}
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteTables tables = ignite.tables();
> sql("CREATE TABLE vals (\"Id\" INTEGER PRIMARY KEY, val VARCHAR)");
> sql("INSERT INTO vals VALUES(1, '1')");
> Table vals = tables.table("vals");
> Tuple val1 = Tuple.create(Map.of("id", 2, "val", "1"));
> vals.recordView().insert(null, val1);
> Tuple val2 = Tuple.create(Map.of("ID", 2, "val", "2"));
> vals.recordView().insert(null, val2);
> Tuple val3 = Tuple.create(Map.of("\"Id\"", 3, "val", "3"));
> // Error Missed key column: Id
> vals.recordView().insert(null, val3);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21971) Extend test coverage for SQL F051-07(Basic date and time. LOCALTIME)
[ https://issues.apache.org/jira/browse/IGNITE-21971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-21971. --- Resolution: Done Fixed in IGNITE-21970 > Extend test coverage for SQL F051-07(Basic date and time. LOCALTIME) > > > Key: IGNITE-21971 > URL: https://issues.apache.org/jira/browse/IGNITE-21971 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F051-07(Basic date and time. LOCALTIME) is poor. > Let's increase the test coverage. > > ref - org.apache.ignite.internal.sql.engine.ItFunctionsTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21972) Extend test coverage for SQL F051-08(Basic date and time. LOCALTIMESTAMP)
[ https://issues.apache.org/jira/browse/IGNITE-21972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21972: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Extend test coverage for SQL F051-08(Basic date and time. LOCALTIMESTAMP) > - > > Key: IGNITE-21972 > URL: https://issues.apache.org/jira/browse/IGNITE-21972 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL F051-08(Basic date and time. LOCALTIMESTAMP) is poor. > Let's increase the test coverage. > > ref - org.apache.ignite.internal.sql.engine.ItFunctionsTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-21969) Extend test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE statement: ADD COLUMN clause)
[ https://issues.apache.org/jira/browse/IGNITE-21969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reopened IGNITE-21969: --- > Extend test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE > statement: ADD COLUMN clause) > - > > Key: IGNITE-21969 > URL: https://issues.apache.org/jira/browse/IGNITE-21969 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE > statement: ADD COLUMN clause) is poor. > Let's increase the test coverage. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21969) Extend test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE statement: ADD COLUMN clause)
[ https://issues.apache.org/jira/browse/IGNITE-21969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-21969. --- Resolution: Duplicate > Extend test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE > statement: ADD COLUMN clause) > - > > Key: IGNITE-21969 > URL: https://issues.apache.org/jira/browse/IGNITE-21969 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE > statement: ADD COLUMN clause) is poor. > Let's increase the test coverage. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21969) Extend test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE statement: ADD COLUMN clause)
[ https://issues.apache.org/jira/browse/IGNITE-21969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21969: - Assignee: Andrey Mashenkov > Extend test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE > statement: ADD COLUMN clause) > - > > Key: IGNITE-21969 > URL: https://issues.apache.org/jira/browse/IGNITE-21969 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F031-04(Basic schema manipulation. ALTER TABLE > statement: ADD COLUMN clause) is poor. > Let's increase the test coverage. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21972) Extend test coverage for SQL F051-08(Basic date and time. LOCALTIMESTAMP)
[ https://issues.apache.org/jira/browse/IGNITE-21972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21972: - Assignee: Andrey Mashenkov > Extend test coverage for SQL F051-08(Basic date and time. LOCALTIMESTAMP) > - > > Key: IGNITE-21972 > URL: https://issues.apache.org/jira/browse/IGNITE-21972 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL F051-08(Basic date and time. LOCALTIMESTAMP) is poor. > Let's increase the test coverage. > > ref - org.apache.ignite.internal.sql.engine.ItFunctionsTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21970) Extend test coverage for SQL F051-06(Basic date and time. CURRENT_DATE)
[ https://issues.apache.org/jira/browse/IGNITE-21970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21970: - Assignee: Andrey Mashenkov > Extend test coverage for SQL F051-06(Basic date and time. CURRENT_DATE) > --- > > Key: IGNITE-21970 > URL: https://issues.apache.org/jira/browse/IGNITE-21970 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL F051-06(Basic date and time. CURRENT_DATE) is poor. > Let's increase the test coverage. > > ref - org.apache.ignite.internal.sql.engine.ItFunctionsTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-21983) Extend test coverage for SQL T031(BOOLEAN data type)
[ https://issues.apache.org/jira/browse/IGNITE-21983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reopened IGNITE-21983: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Extend test coverage for SQL T031(BOOLEAN data type) > > > Key: IGNITE-21983 > URL: https://issues.apache.org/jira/browse/IGNITE-21983 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Test coverage for SQL T031(BOOLEAN data type) is poor. > Let's increase the test coverage. > > ref - test_boolean_cast.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22337) Support CURRENT_DATE/LOCAL_TIME/NOW as functional default
Andrey Mashenkov created IGNITE-22337: - Summary: Support CURRENT_DATE/LOCAL_TIME/NOW as functional default Key: IGNITE-22337 URL: https://issues.apache.org/jira/browse/IGNITE-22337 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov Let's allow CURRENT_DATE/LOCAL_TIME/NOW functions in functional defaults for columns of temporal types. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22336) Fix CURRENT_DATE/LOCAL_TIME/NOW implementations
[ https://issues.apache.org/jira/browse/IGNITE-22336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22336: -- Description: SQL standard implies the functions, which returns current data/time, should return same value for each call within the same query. In distributed SQL, we should return the same value for all the fragments. was: SQL standard implies the CURRENT_DATE function should return same value for each call within the same query. In distributed SQL, we should return the same value for all the fragments. > Fix CURRENT_DATE/LOCAL_TIME/NOW implementations > --- > > Key: IGNITE-22336 > URL: https://issues.apache.org/jira/browse/IGNITE-22336 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > SQL standard implies the functions, which returns current data/time, should > return same value for each call within the same query. > In distributed SQL, we should return the same value for all the fragments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22336) Fix CURRENT_DATE/LOCAL_TIME/NOW implementations
[ https://issues.apache.org/jira/browse/IGNITE-22336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22336: -- Summary: Fix CURRENT_DATE/LOCAL_TIME/NOW implementations (was: Fix CURRENT_DATE implementation) > Fix CURRENT_DATE/LOCAL_TIME/NOW implementations > --- > > Key: IGNITE-22336 > URL: https://issues.apache.org/jira/browse/IGNITE-22336 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > SQL standard implies the CURRENT_DATE function should return same value for > each call within the same query. > In distributed SQL, we should return the same value for all the fragments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22336) Fix CURRENT_DATE implementation
Andrey Mashenkov created IGNITE-22336: - Summary: Fix CURRENT_DATE implementation Key: IGNITE-22336 URL: https://issues.apache.org/jira/browse/IGNITE-22336 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov SQL standard implies the CURRENT_DATE function should return same value for each call within the same query. In distributed SQL, we should return the same value for all the fragments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21970) Extend test coverage for SQL F051-06(Basic date and time. CURRENT_DATE)
[ https://issues.apache.org/jira/browse/IGNITE-21970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21970: -- Fix Version/s: 3.0.0-beta2 > Extend test coverage for SQL F051-06(Basic date and time. CURRENT_DATE) > --- > > Key: IGNITE-21970 > URL: https://issues.apache.org/jira/browse/IGNITE-21970 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL F051-06(Basic date and time. CURRENT_DATE) is poor. > Let's increase the test coverage. > > ref - org.apache.ignite.internal.sql.engine.ItFunctionsTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22323) Remove duplicate tests from ItFunctionsTest
Andrey Mashenkov created IGNITE-22323: - Summary: Remove duplicate tests from ItFunctionsTest Key: IGNITE-22323 URL: https://issues.apache.org/jira/browse/IGNITE-22323 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov Some tests in ItFunctionsTest duplicates SQL Logic test and can be safely dropped. Most of tests could be moved to SQL Logic test suite. Let’s just do this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19331) Sql. CAST with Boolean operations is failed.
[
https://issues.apache.org/jira/browse/IGNITE-19331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-19331:
-
Assignee: Andrey Mashenkov
> Sql. CAST with Boolean operations is failed.
>
>
> Key: IGNITE-19331
> URL: https://issues.apache.org/jira/browse/IGNITE-19331
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> SqlRunner tests are failed
> {noformat}
> /sql/test_boolean_cast.test_ignore
> {noformat}
> {noformat}
> query T
> SELECT CAST(CAST('1' AS float) AS BOOLEAN)
>
> true
> {noformat}
> {noformat}
> Not expected result at: (test_try_cast.test:150). [row=0, col=0,
> expected=true, actual=false]
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkEquals(SqlScriptRunner.java:635)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResultTuples(SqlScriptRunner.java:604)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResult(SqlScriptRunner.java:583)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:555)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 "Boolean data type" and F571 "Truth values test" features for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 "Boolean datatype" and F571 "Truth values test" features for details. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 "Boolean data type" and F571 "Truth values test" features for > details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 "Boolean datatype" and F571 "Truth values test" features for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 and F503 features for details. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 "Boolean datatype" and F571 "Truth values test" features for > details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 feature for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 feature for details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 and F503 features for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 feature for details. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 and F503 features for details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
Andrey Mashenkov created IGNITE-22297: - Summary: SQL. Support UNKNOWN boolean literal Key: IGNITE-22297 URL: https://issues.apache.org/jira/browse/IGNITE-22297 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21983) Extend test coverage for SQL T031(BOOLEAN data type)
[ https://issues.apache.org/jira/browse/IGNITE-21983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21983: -- Fix Version/s: 3.0.0-beta2 > Extend test coverage for SQL T031(BOOLEAN data type) > > > Key: IGNITE-21983 > URL: https://issues.apache.org/jira/browse/IGNITE-21983 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL T031(BOOLEAN data type) is poor. > Let's increase the test coverage. > > ref - test_boolean_cast.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21983) Extend test coverage for SQL T031(BOOLEAN data type)
[ https://issues.apache.org/jira/browse/IGNITE-21983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21983: - Assignee: Andrey Mashenkov > Extend test coverage for SQL T031(BOOLEAN data type) > > > Key: IGNITE-21983 > URL: https://issues.apache.org/jira/browse/IGNITE-21983 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T031(BOOLEAN data type) is poor. > Let's increase the test coverage. > > ref - test_boolean_cast.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19670) Improve CatalogService test coverage.
[ https://issues.apache.org/jira/browse/IGNITE-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19670: -- Fix Version/s: 3.0.0-beta2 > Improve CatalogService test coverage. > - > > Key: IGNITE-19670 > URL: https://issues.apache.org/jira/browse/IGNITE-19670 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3, tech-debt-test > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1. CatalogServiceSelftTest.testCreateTable (+testDropTable) looks a bit > complicated. It checks creation of more than one table. Let's simplify the > test by reverting last changes > 2. We use shared counter to generate unique identifier for schema objects. > Some tests checks schema object id, and some doesn't. Let's move > schema-object's id check into separate test, to verify which command > increments the counter, and which doesn't. > 3. Let's add a test that will check ABA problem. E.g. create-drop-create > table (or index) with same name and check the object can be resolved > correctly by name and by id (regarding object versioning in Catalog, of > course). > 4. Move Catalog operations tests to separate class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22221) Implement SQL F393 feature (Unicode escapes in literals) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-1: -- Description: Let's support Unicode escapes in literals (F393 SQL feature) and unmute tests. (was: We don't have at all any tests for F393(Unicode escapes in literals) SQL feature. Let's cover it and create tickets to fix them in case find any issues related to the covered area) > Implement SQL F393 feature (Unicode escapes in literals) feature by tests > - > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Let's support Unicode escapes in literals (F393 SQL feature) and unmute tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22221) Implement SQL F393 feature (Unicode escapes in literals) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-1: -- Epic Link: (was: IGNITE-21915) > Implement SQL F393 feature (Unicode escapes in literals) feature by tests > - > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F393(Unicode escapes in literals) SQL > feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22221) Implement SQL F393 feature (Unicode escapes in literals) feature by tests
Andrey Mashenkov created IGNITE-1: - Summary: Implement SQL F393 feature (Unicode escapes in literals) feature by tests Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov Assignee: Andrey Mashenkov We don't have at all any tests for F393(Unicode escapes in literals) SQL feature. Let's cover it and create tickets to fix them in case find any issues related to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21942) Cover SQL F393(Unicode escapes in literals) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21942: - Assignee: Andrey Mashenkov > Cover SQL F393(Unicode escapes in literals) feature by tests > > > Key: IGNITE-21942 > URL: https://issues.apache.org/jira/browse/IGNITE-21942 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F393(Unicode escapes in literals) SQL > feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19082) Catalog. Cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19082: -- Description: Let's * ensure Catalog is used by default as a single schema management point by TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * -drop schema related code from configuration.- * -drop outdated code from TableManager, IndexManager, SqlSchemaManager, SchemaRegistry.- * Let’s remove using/keeping schema name instead of schema id (NewIndexEntry class as example) was: Let's * ensure Catalog is used by default as a single schema management point by TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * drop schema related code from configuration. * drop outdated code from TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * make a PR for merging feature branch to main (if applicable). * ensure there are end-to-end tests for the cases (if applicable) described in CatalogServiceSelfTest. Also drop InternalSchemaTest. * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry class as example) > Catalog. Cleanup dead code. > --- > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * -drop schema related code from configuration.- > * -drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry.- > * Let’s remove using/keeping schema name instead of schema id (NewIndexEntry > class as example) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21941) Cover SQL F391(Long identifiers) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21941: - Assignee: Andrey Mashenkov > Cover SQL F391(Long identifiers) feature by tests > - > > Key: IGNITE-21941 > URL: https://issues.apache.org/jira/browse/IGNITE-21941 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F391(Long identifiers) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22161) Sql. Infinity error-loop for simple query
[
https://issues.apache.org/jira/browse/IGNITE-22161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844234#comment-17844234
]
Andrey Mashenkov commented on IGNITE-22161:
---
[~mzhuravkov] , [~korlov] would you please do review.
> Sql. Infinity error-loop for simple query
> -
>
> Key: IGNITE-22161
> URL: https://issues.apache.org/jira/browse/IGNITE-22161
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> An infinity error loop for the following query occurred:
> {code:java}
> CREATE TABLE cc_(key int, val varchar DEFAULT \"defaultValue\" primary
> key){code}
> error:
> {code:java}
> [2024-05-02T17:04:41,397][ERROR][%isaat_n_1%JRaft-FSMCaller-Disruptormetastorage_stripe_0-0][FailureProcessor]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.util.concurrent.CompletionException:
> java.lang.IllegalArgumentException: No enum constant
> org.apache.ignite.internal.schema.DefaultValueGenerator.defaultValue]]
> java.util.concurrent.CompletionException:
> java.lang.IllegalArgumentException: No enum constant
> org.apache.ignite.internal.schema.DefaultValueGenerator.defaultValue
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.andTree(CompletableFuture.java:1527)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.allOf(CompletableFuture.java:2419)
> ~[?:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:258)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
> ~[main/:?]
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
> ~[?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> ~[?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> ~[?:?]
> at java.base/java.lang.Thread.run(Thread.java:842) [?:?]
> Caused by: java.lang.IllegalArgumentException: No enum constant
> org.apache.ignite.internal.schema.DefaultValueGenerator.defaultValue
> at java.base/java.lang.Enum.valueOf(Enum.java:273) ~[?:?]
> at
> org.apache.ignite.internal.schema.DefaultValueGenerator.valueOf(DefaultValueGenerator.java:29)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:138)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:162)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.SchemaUtils.prepareSchemaDescriptor(SchemaUtils.java:37)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.SchemaManager.onTableCreatedOrAltered(SchemaManager.java:147)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.SchemaManager.onTableCreated(SchemaManager.java:119)
> ~[main/:?]
> at
> org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:91)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:562)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:529)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:314)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
> ~[main/:?]
> ... 6 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22161) Sql. Infinity error-loop for simple query
[
https://issues.apache.org/jira/browse/IGNITE-22161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-22161:
-
Assignee: Andrey Mashenkov
> Sql. Infinity error-loop for simple query
> -
>
> Key: IGNITE-22161
> URL: https://issues.apache.org/jira/browse/IGNITE-22161
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Blocker
> Labels: ignite-3
>
> An infinity error loop for the following query occurred:
> {code:java}
> CREATE TABLE cc_(key int, val varchar DEFAULT \"defaultValue\" primary
> key){code}
> error:
> {code:java}
> [2024-05-02T17:04:41,397][ERROR][%isaat_n_1%JRaft-FSMCaller-Disruptormetastorage_stripe_0-0][FailureProcessor]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.util.concurrent.CompletionException:
> java.lang.IllegalArgumentException: No enum constant
> org.apache.ignite.internal.schema.DefaultValueGenerator.defaultValue]]
> java.util.concurrent.CompletionException:
> java.lang.IllegalArgumentException: No enum constant
> org.apache.ignite.internal.schema.DefaultValueGenerator.defaultValue
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.andTree(CompletableFuture.java:1527)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.allOf(CompletableFuture.java:2419)
> ~[?:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:258)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
> ~[main/:?]
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
> ~[?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> ~[?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> ~[?:?]
> at java.base/java.lang.Thread.run(Thread.java:842) [?:?]
> Caused by: java.lang.IllegalArgumentException: No enum constant
> org.apache.ignite.internal.schema.DefaultValueGenerator.defaultValue
> at java.base/java.lang.Enum.valueOf(Enum.java:273) ~[?:?]
> at
> org.apache.ignite.internal.schema.DefaultValueGenerator.valueOf(DefaultValueGenerator.java:29)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:138)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:162)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.SchemaUtils.prepareSchemaDescriptor(SchemaUtils.java:37)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.SchemaManager.onTableCreatedOrAltered(SchemaManager.java:147)
> ~[main/:?]
> at
> org.apache.ignite.internal.schema.SchemaManager.onTableCreated(SchemaManager.java:119)
> ~[main/:?]
> at
> org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:91)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:562)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:529)
> ~[main/:?]
> at
> org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:314)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
> ~[main/:?]
> ... 6 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22156) Improve test coverage for UpgradingRowAdapter.
[ https://issues.apache.org/jira/browse/IGNITE-22156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22156: -- Fix Version/s: 3.0.0-beta2 > Improve test coverage for UpgradingRowAdapter. > -- > > Key: IGNITE-22156 > URL: https://issues.apache.org/jira/browse/IGNITE-22156 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Critical > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > As fow now, we have no unit tests for UpgradingRowAdapter class at all. > `UpgradingRowAdapter` class inherits a bunch of methods from various > interfaces, which are implemented in parent classes. We found few issues when > some of these methods must be overridden in `UpgradingRowAdapter` due to > different semantic. > Also, with the current approach, the one may add a method that implementation > will have incorrect behavior in UpgradingRowAdapter. > Most likely, `inheritance` from base `Row` class should be changed to > `delegation`, and a `Row` be an interface. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22156) Improve test coverage for UpgradingRowAdapter.
[ https://issues.apache.org/jira/browse/IGNITE-22156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-22156: - Assignee: Andrey Mashenkov > Improve test coverage for UpgradingRowAdapter. > -- > > Key: IGNITE-22156 > URL: https://issues.apache.org/jira/browse/IGNITE-22156 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Critical > Labels: ignite-3, tech-debt > > As fow now, we have no unit tests for UpgradingRowAdapter class at all. > `UpgradingRowAdapter` class inherits a bunch of methods from various > interfaces, which are implemented in parent classes. We found few issues when > some of these methods must be overridden in `UpgradingRowAdapter` due to > different semantic. > Also, with the current approach, the one may add a method that implementation > will have incorrect behavior in UpgradingRowAdapter. > Most likely, `inheritance` from base `Row` class should be changed to > `delegation`, and a `Row` be an interface. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22156) Improve test coverage for UpgradingRowAdapter.
Andrey Mashenkov created IGNITE-22156: - Summary: Improve test coverage for UpgradingRowAdapter. Key: IGNITE-22156 URL: https://issues.apache.org/jira/browse/IGNITE-22156 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov As fow now, we have no unit tests for UpgradingRowAdapter class at all. `UpgradingRowAdapter` class inherits a bunch of methods from various interfaces, which are implemented in parent classes. We found few issues when some of these methods must be overridden in `UpgradingRowAdapter` due to different semantic. Also, with the current approach, the one may add a method that implementation will have incorrect behavior in UpgradingRowAdapter. Most likely, `inheritance` from base `Row` class should be changed to `delegation`, and a `Row` be an interface. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21731) Sql. Split TableRowConverter#toBinaryRow on two methods
[
https://issues.apache.org/jira/browse/IGNITE-21731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-21731:
--
Fix Version/s: 3.0.0-beta2
> Sql. Split TableRowConverter#toBinaryRow on two methods
> ---
>
> Key: IGNITE-21731
> URL: https://issues.apache.org/jira/browse/IGNITE-21731
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, method
> {{org.apache.ignite.internal.sql.engine.exec.TableRowConverter#toBinaryRow}}
> accepts boolean flag {{key}} and creates row with regard to this flag.
> Perhaps, the api will be cleaner if we split this method on two parts:
> {{toKeyRow}} and {{toFullRow}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21732) Sql. Split TableRowConverterImpl on two different implementations
[
https://issues.apache.org/jira/browse/IGNITE-21732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-21732:
--
Fix Version/s: 3.0.0-beta2
> Sql. Split TableRowConverterImpl on two different implementations
> -
>
> Key: IGNITE-21732
> URL: https://issues.apache.org/jira/browse/IGNITE-21732
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, {{TableRowConverterImpl}} implements two strategies of conversion:
> with and without field trimming. To make code simper and to remove branching
> from a hot path let's split this class on two (one per each strategy)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21731) Sql. Split TableRowConverter#toBinaryRow on two methods
[
https://issues.apache.org/jira/browse/IGNITE-21731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-21731:
-
Assignee: Andrey Mashenkov
> Sql. Split TableRowConverter#toBinaryRow on two methods
> ---
>
> Key: IGNITE-21731
> URL: https://issues.apache.org/jira/browse/IGNITE-21731
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> Currently, method
> {{org.apache.ignite.internal.sql.engine.exec.TableRowConverter#toBinaryRow}}
> accepts boolean flag {{key}} and creates row with regard to this flag.
> Perhaps, the api will be cleaner if we split this method on two parts:
> {{toKeyRow}} and {{toFullRow}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21732) Sql. Split TableRowConverterImpl on two different implementations
[
https://issues.apache.org/jira/browse/IGNITE-21732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-21732:
-
Assignee: Andrey Mashenkov (was: Evgeny Stanilovsky)
> Sql. Split TableRowConverterImpl on two different implementations
> -
>
> Key: IGNITE-21732
> URL: https://issues.apache.org/jira/browse/IGNITE-21732
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, {{TableRowConverterImpl}} implements two strategies of conversion:
> with and without field trimming. To make code simper and to remove branching
> from a hot path let's split this class on two (one per each strategy)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21948) Rethink distributed aggregates converter rules.
[ https://issues.apache.org/jira/browse/IGNITE-21948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21948: - Assignee: Andrey Mashenkov > Rethink distributed aggregates converter rules. > --- > > Key: IGNITE-21948 > URL: https://issues.apache.org/jira/browse/IGNITE-21948 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, perfomance, sql > > *Motivation.* > We convert LogicalAggregate to map-reduce unconditionally (if possible), > which blows plan search space. > Some plans, which have reduce-phase followed by map-phase without Exchange, > make no sense and will be thrown away after applying cost model (if no - > there is a bug). > *Suggestion.* > What if we will emit only plans with colocated aggregates? > We can write rules to pushdown colocated aggregate through Exchange via > splitting into map-reduce phases, if colocation can't be preserved. > If Exchange can preserve colocation, then aggregate is pushed gown without > splitting. > Let's investigate, if we can eliminate (or significantly decrease number of > plans) > # with Exchange-less Reduce->Map > # map-reduce aggregates on colocated data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21948) Rethink distributed aggregates converter rules.
[ https://issues.apache.org/jira/browse/IGNITE-21948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21948: -- Labels: ignite-3 perfomance sql (was: ignite-3 perfomance) > Rethink distributed aggregates converter rules. > --- > > Key: IGNITE-21948 > URL: https://issues.apache.org/jira/browse/IGNITE-21948 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, perfomance, sql > > *Motivation.* > We convert LogicalAggregate to map-reduce unconditionally (if possible), > which blows plan search space. > Some plans, which have reduce-phase followed by map-phase without Exchange, > make no sense and will be thrown away after applying cost model (if no - > there is a bug). > *Suggestion.* > What if we will emit only plans with colocated aggregates? > We can write rules to pushdown colocated aggregate through Exchange via > splitting into map-reduce phases, if colocation can't be preserved. > If Exchange can preserve colocation, then aggregate is pushed gown without > splitting. > Let's investigate, if we can eliminate (or significantly decrease number of > plans) > # with Exchange-less Reduce->Map > # map-reduce aggregates on colocated data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21954) Reuse Calcite map-reduce aggregates code.
[
https://issues.apache.org/jira/browse/IGNITE-21954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-21954:
--
Labels: ignite-3 sql tech-debt (was: ignite-3 tech-debt)
> Reuse Calcite map-reduce aggregates code.
> -
>
> Key: IGNITE-21954
> URL: https://issues.apache.org/jira/browse/IGNITE-21954
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3, sql, tech-debt
>
> *Motivation*
> As for now we have custom code that splits aggregate function into map-reduce
> stages. See class/method usage for details:
>
> {code:java}
> MapReduceAggregates.buildAggregates{code}
>
> Some functions (e.g. AVG) are split into 2 functions which may have
> incompatible types (e.g. COUNT returns BIGINT on map-phase, but SUM on
> reduce-phase requires DECIMAL).
> This forces adding a Projection in between, but this additional stage looks
> synthetic and rises costs.
> I've found Calcite already have `AggregateReduceFunctionsRule`, which splits
> functions in different way (using `CASE-WHEN` clause instead of Project), and
> can be reused.
> *Suggestion*
> Let's try to reuse Calcite rule and/or splitting functions, and drop
> duplicating code from our codebase.
> Otherwise, if there are obstacles, go the similar way at least.
> Fix planner tests, which expects a Project between map and reduce phases.
> *Expectation*
> After this fix, we should observe no projection in between map and reduce
> aggregate phases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22014) IN clause doesn't support NULL literals in some cases
Andrey Mashenkov created IGNITE-22014:
-
Summary: IN clause doesn't support NULL literals in some cases
Key: IGNITE-22014
URL: https://issues.apache.org/jira/browse/IGNITE-22014
Project: Ignite
Issue Type: Test
Reporter: Andrey Mashenkov
Next SqlLogicTests fails due to null columns.
{code:java}
SELECT (1, 'hello') IN ((1, NULL));
SELECT (1, NULL) IN ((1, NULL));
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20819) Concurrent micronaut server startup fails sometimes
[ https://issues.apache.org/jira/browse/IGNITE-20819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-20819: - Assignee: Andrey Mashenkov (was: Aleksandr) > Concurrent micronaut server startup fails sometimes > --- > > Key: IGNITE-20819 > URL: https://issues.apache.org/jira/browse/IGNITE-20819 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > We see the flaky tests in CI with the root cause described here: > https://github.com/micronaut-projects/micronaut-core/issues/10091 > We have to use a workaround with a global lock for a while. After the issue > in the upstream is fixed, we can drop the workaround. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21920) Cover SQL E051-04 (Basic query specification, GROUP BY can contain columns not in ) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21920: -- Fix Version/s: 3.0.0-beta2 > Cover SQL E051-04 (Basic query specification, GROUP BY can contain columns > not in ) feature by tests > - > > Key: IGNITE-21920 > URL: https://issues.apache.org/jira/browse/IGNITE-21920 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We don't have at all any tests for E051-04 (Basic query specification, GROUP > BY can contain columns not in ) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21920) Cover SQL E051-04 (Basic query specification, GROUP BY can contain columns not in ) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21920: - Assignee: Andrey Mashenkov > Cover SQL E051-04 (Basic query specification, GROUP BY can contain columns > not in ) feature by tests > - > > Key: IGNITE-21920 > URL: https://issues.apache.org/jira/browse/IGNITE-21920 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for E051-04 (Basic query specification, GROUP > BY can contain columns not in ) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21914) Cover SQL T631(IN predicate with one list element) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-21914: - Assignee: Andrey Mashenkov > Cover SQL T631(IN predicate with one list element) feature by tests > --- > > Key: IGNITE-21914 > URL: https://issues.apache.org/jira/browse/IGNITE-21914 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for T631 (IN predicate with one list element) > SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19719) Make CatalogDataStorageDescriptor support for each storage engine
[ https://issues.apache.org/jira/browse/IGNITE-19719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19719: -- Epic Link: IGNITE-21991 (was: IGNITE-21211) > Make CatalogDataStorageDescriptor support for each storage engine > - > > Key: IGNITE-19719 > URL: https://issues.apache.org/jira/browse/IGNITE-19719 > Project: Ignite > Issue Type: Improvement > Environment: Catalog service Part 3 >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, we do not have the ability to implement > *org.apache.ignite.internal.catalog.descriptors.CatalogDataStorageDescriptor* > for each storage engine, we need to come up with a mechanism for how to do > this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21608) Fix catalog compaction.
[ https://issues.apache.org/jira/browse/IGNITE-21608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21608: -- Epic Link: IGNITE-21991 (was: IGNITE-21211) > Fix catalog compaction. > --- > > Key: IGNITE-21608 > URL: https://issues.apache.org/jira/browse/IGNITE-21608 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Catalog compaction was disabled in IGNITE-21585, because we need consensus on > all the nodes about safe timestamp/version the Catalog` history could be > truncated to. > Let's enable compations and fix all the issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20046) Improve the Catalog interfaces
[ https://issues.apache.org/jira/browse/IGNITE-20046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20046: -- Labels: ignite-3 tech-debt (was: ignite-3) > Improve the Catalog interfaces > -- > > Key: IGNITE-20046 > URL: https://issues.apache.org/jira/browse/IGNITE-20046 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > Catalog related interfaces and classes are missing javadocs, need to fix this. > CatalogService getters, which accepts ID and timestamp, looks useless and, > probably, could be removed. > Let's also change timestamp type `long->HybridTimestamp` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19670) Improve CatalogService test coverage.
[ https://issues.apache.org/jira/browse/IGNITE-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19670: -- Epic Link: IGNITE-21991 (was: IGNITE-21211) > Improve CatalogService test coverage. > - > > Key: IGNITE-19670 > URL: https://issues.apache.org/jira/browse/IGNITE-19670 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt-test > > 1. CatalogServiceSelftTest.testCreateTable (+testDropTable) looks a bit > complicated. It checks creation of more than one table. Let's simplify the > test by reverting last changes > 2. We use shared counter to generate unique identifier for schema objects. > Some tests checks schema object id, and some doesn't. Let's move > schema-object's id check into separate test, to verify which command > increments the counter, and which doesn't. > 3. Let's add a test that will check ABA problem. E.g. create-drop-create > table (or index) with same name and check the object can be resolved > correctly by name and by id (regarding object versioning in Catalog, of > course). > 4. Move Catalog operations tests to separate class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20095) Sql. Map part of MAP/REDUCE aggregate sometimes can not be moved past Exchange.
[ https://issues.apache.org/jira/browse/IGNITE-20095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-20095. --- Resolution: Duplicate Fixed within IGNITE-21580 > Sql. Map part of MAP/REDUCE aggregate sometimes can not be moved past > Exchange. > --- > > Key: IGNITE-20095 > URL: https://issues.apache.org/jira/browse/IGNITE-20095 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > See examples in MapReduceSortAggregatePlannerTest. > Looks like, Map aggregate can't utilize sorting from the input in some cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
