[jira] [Updated] (IGNITE-23277) Calcite. Wrong cast to TIMESTAMP WITH LOCAL TIMEZONE
[
https://issues.apache.org/jira/browse/IGNITE-23277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23277:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Calcite. Wrong cast to TIMESTAMP WITH LOCAL TIMEZONE
>
>
> Key: IGNITE-23277
> URL: https://issues.apache.org/jira/browse/IGNITE-23277
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
>
> A value from a `VARCHAR` column is incorrectly casted into a `TIMESTAMP WITH
> LOCAL TIME ZONE` column. The timezone is skipped.
> Reproducer:
> {code:java}
> @Test
> public void testCastToTimestampWithLocalTimeZoneFromStringColumn() {
> TimeZone tz = TimeZone.getDefault();
> try {
> sql("CREATE TABLE src (id INT PRIMARY KEY, str_date
> VARCHAR(100))");
> sql("INSERT INTO src VALUES (1, '2024-07-21 12:00:00')");
> sql("CREATE TABLE test (val TIMESTAMP WITH LOCAL TIME ZONE)");
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.ofHours(4)));
> assertQuery("INSERT INTO test SELECT str_date FROM src WHERE id =
> 1").check();
> TimeZone.setDefault(tz);
> assertQuery("SELECT val FROM test")
> .returns(LocalDateTime.of(2024,7, 21, 8, 0, 0))
> .check();
> } finally {
> TimeZone.setDefault(tz);
> }
> }
> {code}
> Adoption of #IGNITE-22780
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23278) Calcite. NPE at table creation with TIMESTAMP WITH TIME ZONE type
[
https://issues.apache.org/jira/browse/IGNITE-23278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23278:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Calcite. NPE at table creation with TIMESTAMP WITH TIME ZONE type
> -
>
> Key: IGNITE-23278
> URL: https://issues.apache.org/jira/browse/IGNITE-23278
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE test (val TIMESTAMP WITH TIME ZONE)");
> {code}
> Error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.toQueryEntity(DdlCommandHandler.java:330)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.handle0(DdlCommandHandler.java:141)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.handle(DdlCommandHandler.java:106)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeDdl(ExecutionServiceImpl.java:528)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:518)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.lambda$parseAndProcessQuery$6(CalciteQueryProcessor.java:530)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.processQuery(CalciteQueryProcessor.java:641)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.parseAndProcessQuery(CalciteQueryProcessor.java:518)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:393)
> ~[classes/:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23278) Calcite. NPE at table creation with TIMESTAMP WITH TIME ZONE type
[
https://issues.apache.org/jira/browse/IGNITE-23278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23278:
--
Labels: ise (was: )
> Calcite. NPE at table creation with TIMESTAMP WITH TIME ZONE type
> -
>
> Key: IGNITE-23278
> URL: https://issues.apache.org/jira/browse/IGNITE-23278
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE test (val TIMESTAMP WITH TIME ZONE)");
> {code}
> Error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.toQueryEntity(DdlCommandHandler.java:330)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.handle0(DdlCommandHandler.java:141)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.handle(DdlCommandHandler.java:106)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeDdl(ExecutionServiceImpl.java:528)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:518)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.lambda$parseAndProcessQuery$6(CalciteQueryProcessor.java:530)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.processQuery(CalciteQueryProcessor.java:641)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.parseAndProcessQuery(CalciteQueryProcessor.java:518)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:393)
> ~[classes/:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23278) Calcite. NPE at table creation with TIMESTAMP WITH TIME ZONE type
Vladimir Steshin created IGNITE-23278:
-
Summary: Calcite. NPE at table creation with TIMESTAMP WITH TIME
ZONE type
Key: IGNITE-23278
URL: https://issues.apache.org/jira/browse/IGNITE-23278
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
Reproducer:
{code:java}
sql("CREATE TABLE test (val TIMESTAMP WITH TIME ZONE)");
{code}
Error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.toQueryEntity(DdlCommandHandler.java:330)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.handle0(DdlCommandHandler.java:141)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.ddl.DdlCommandHandler.handle(DdlCommandHandler.java:106)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeDdl(ExecutionServiceImpl.java:528)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:518)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.lambda$parseAndProcessQuery$6(CalciteQueryProcessor.java:530)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.processQuery(CalciteQueryProcessor.java:641)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.parseAndProcessQuery(CalciteQueryProcessor.java:518)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:393)
~[classes/:?]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23277) Calcite. Wrong cast to TIMESTAMP WITH LOCAL TIMEZONE
[
https://issues.apache.org/jira/browse/IGNITE-23277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23277:
--
Labels: ise (was: )
> Calcite. Wrong cast to TIMESTAMP WITH LOCAL TIMEZONE
>
>
> Key: IGNITE-23277
> URL: https://issues.apache.org/jira/browse/IGNITE-23277
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> A value from a `VARCHAR` column is incorrectly casted into a `TIMESTAMP WITH
> LOCAL TIME ZONE` column. The timezone is skipped.
> Reproducer:
> {code:java}
> @Test
> public void testCastToTimestampWithLocalTimeZoneFromStringColumn() {
> TimeZone tz = TimeZone.getDefault();
> try {
> sql("CREATE TABLE src (id INT PRIMARY KEY, str_date
> VARCHAR(100))");
> sql("INSERT INTO src VALUES (1, '2024-07-21 12:00:00')");
> sql("CREATE TABLE test (val TIMESTAMP WITH LOCAL TIME ZONE)");
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.ofHours(4)));
> assertQuery("INSERT INTO test SELECT str_date FROM src WHERE id =
> 1").check();
> TimeZone.setDefault(tz);
> assertQuery("SELECT val FROM test")
> .returns(LocalDateTime.of(2024,7, 21, 8, 0, 0))
> .check();
> } finally {
> TimeZone.setDefault(tz);
> }
> }
> {code}
> Adoption of #IGNITE-22780
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23277) Calcite. Wrong cast to TIMESTAMP WITH LOCAL TIMEZONE
Vladimir Steshin created IGNITE-23277:
-
Summary: Calcite. Wrong cast to TIMESTAMP WITH LOCAL TIMEZONE
Key: IGNITE-23277
URL: https://issues.apache.org/jira/browse/IGNITE-23277
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
A value from a `VARCHAR` column is incorrectly casted into a `TIMESTAMP WITH
LOCAL TIME ZONE` column. The timezone is skipped.
Reproducer:
{code:java}
@Test
public void testCastToTimestampWithLocalTimeZoneFromStringColumn() {
TimeZone tz = TimeZone.getDefault();
try {
sql("CREATE TABLE src (id INT PRIMARY KEY, str_date VARCHAR(100))");
sql("INSERT INTO src VALUES (1, '2024-07-21 12:00:00')");
sql("CREATE TABLE test (val TIMESTAMP WITH LOCAL TIME ZONE)");
TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.ofHours(4)));
assertQuery("INSERT INTO test SELECT str_date FROM src WHERE id =
1").check();
TimeZone.setDefault(tz);
assertQuery("SELECT val FROM test")
.returns(LocalDateTime.of(2024,7, 21, 8, 0, 0))
.check();
} finally {
TimeZone.setDefault(tz);
}
}
{code}
Adoption of #IGNITE-22780
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23251) Calcite. Validate number of passed query parameters.
[
https://issues.apache.org/jira/browse/IGNITE-23251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23251:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Calcite. Validate number of passed query parameters.
>
>
> Key: IGNITE-23251
> URL: https://issues.apache.org/jira/browse/IGNITE-23251
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: calcite, ise
>
> Currently, we do not validate number of the passed query parameters. We
> should produce an error in cases like
> {code:java}
> assrtQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
> {code}
> Adoption of IGNITE-18422
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23251) Calcite. Validate number of passed query parameters.
[
https://issues.apache.org/jira/browse/IGNITE-23251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23251:
--
Labels: calcite ise (was: )
> Calcite. Validate number of passed query parameters.
>
>
> Key: IGNITE-23251
> URL: https://issues.apache.org/jira/browse/IGNITE-23251
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: calcite, ise
>
> Currently, we do not validate number of the passed query parameters. We
> should produce an error in cases like
> {code:java}
> assrtQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
> {code}
> Adoption of IGNITE-18422
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23251) Calcite. Validate number of passed query parameters.
[
https://issues.apache.org/jira/browse/IGNITE-23251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23251:
--
Description:
Currently, we do not validate number of the passed query parameters. We should
produce an error in cases like
{code:java}
assrtQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
{code}
Adoption of IGNITE-18422
was:
Currently, we do not validate number of the passed query parameters. We should
produce an error in cases like
{code:java}
assrtQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
{code}
> Calcite. Validate number of passed query parameters.
>
>
> Key: IGNITE-23251
> URL: https://issues.apache.org/jira/browse/IGNITE-23251
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> Currently, we do not validate number of the passed query parameters. We
> should produce an error in cases like
> {code:java}
> assrtQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
> {code}
> Adoption of IGNITE-18422
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23251) Calcite. Validate number of passed query parameters.
Vladimir Steshin created IGNITE-23251:
-
Summary: Calcite. Validate number of passed query parameters.
Key: IGNITE-23251
URL: https://issues.apache.org/jira/browse/IGNITE-23251
Project: Ignite
Issue Type: Improvement
Reporter: Vladimir Steshin
Currently, we do not validate number of the passed query parameters. We should
produce an error in cases like
{code:java}
assrtQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23179) Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
[
https://issues.apache.org/jira/browse/IGNITE-23179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23179:
--
Description:
The test
{code:java}
@Test
public void testIsNotDistinctFrom() {
executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
null)");
executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
null)");
String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT FROM
i3";
assertQuery(sql)
.returns(1, 1)
.returns(2, 2)
.returns(null, 3)
.check();
}
{code}
fails with:
{code:java}
java.lang.AssertionError: Collections sizes are not equal:
Expected: [[1, 1], [2, 2], [null, 3]]
Actual: [[null, 3]]
{code}
The is an incorrect numeric types coercion with _IS NOT DISTINCT_. Works is the
column type is the same: _INTEGER_.
Adoption of IGNITE-18163.
was:
The test
{code:java}
@Test
public void testIsNotDistinctFrom() {
executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
null)");
executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
null)");
String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT FROM
i3";
assertQuery(sql)
.returns(1, 1)
.returns(2, 2)
.returns(null, 3)
.check();
}
{code}
fails with:
{code:java}
java.lang.AssertionError: Collections sizes are not equal:
Expected: [[1, 1], [2, 2], [null, 3]]
Actual: [[null, 3]]
{code}
The is an incirrect numeric types coercion with _IS NOT DISTINCT_. Works is the
column type is the same: _INTEGER_.
Adoption of IGNITE-18163.
> Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
>
>
> Key: IGNITE-23179
> URL: https://issues.apache.org/jira/browse/IGNITE-23179
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise
> Attachments: IsNotDistinctFromTest.java
>
>
> The test
> {code:java}
> @Test
> public void testIsNotDistinctFrom() {
> executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
> executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
> null)");
> executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
> executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
> null)");
> String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT
> FROM i3";
> assertQuery(sql)
> .returns(1, 1)
> .returns(2, 2)
> .returns(null, 3)
> .check();
> }
> {code}
> fails with:
> {code:java}
> java.lang.AssertionError: Collections sizes are not equal:
> Expected: [[1, 1], [2, 2], [null, 3]]
> Actual: [[null, 3]]
> {code}
> The is an incorrect numeric types coercion with _IS NOT DISTINCT_. Works is
> the column type is the same: _INTEGER_.
> Adoption of IGNITE-18163.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23179) Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
[
https://issues.apache.org/jira/browse/IGNITE-23179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23179:
--
Description:
The test
{code:java}
@Test
public void testIsNotDistinctFrom() {
executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
null)");
executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
null)");
String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT FROM
i3";
assertQuery(sql)
.returns(1, 1)
.returns(2, 2)
.returns(null, 3)
.check();
}
{code}
fails with:
{code:java}
java.lang.AssertionError: Collections sizes are not equal:
Expected: [[1, 1], [2, 2], [null, 3]]
Actual: [[null, 3]]
{code}
The is an incirrect numeric types coercion with _IS NOT DISTINCT_. Works is the
column type is the same: _INTEGER_.
Adoption of IGNITE-18163.
was:
The test
{code:java}
@Test
public void testIsNotDistinctFrom() {
executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
null)");
executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
null)");
String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT FROM
i3";
assertQuery(sql)
.returns(1, 1)
.returns(2, 2)
.returns(null, 3)
.check();
}
{code}
fails with:
{code:java}
java.lang.AssertionError: Collections sizes are not equal:
Expected: [[1, 1], [2, 2], [null, 3]]
Actual: [[null, 3]]
{code}
The is an incirrect numeric types coercion with _IS NOT DISTINCT_. Works is the
column type would be the same (_INTEGER_).
Adoption of IGNITE-18163.
> Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
>
>
> Key: IGNITE-23179
> URL: https://issues.apache.org/jira/browse/IGNITE-23179
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise
> Attachments: IsNotDistinctFromTest.java
>
>
> The test
> {code:java}
> @Test
> public void testIsNotDistinctFrom() {
> executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
> executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
> null)");
> executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
> executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
> null)");
> String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT
> FROM i3";
> assertQuery(sql)
> .returns(1, 1)
> .returns(2, 2)
> .returns(null, 3)
> .check();
> }
> {code}
> fails with:
> {code:java}
> java.lang.AssertionError: Collections sizes are not equal:
> Expected: [[1, 1], [2, 2], [null, 3]]
> Actual: [[null, 3]]
> {code}
> The is an incirrect numeric types coercion with _IS NOT DISTINCT_. Works is
> the column type is the same: _INTEGER_.
> Adoption of IGNITE-18163.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23179) Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
[
https://issues.apache.org/jira/browse/IGNITE-23179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23179:
--
Labels: calcite ise (was: )
> Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
>
>
> Key: IGNITE-23179
> URL: https://issues.apache.org/jira/browse/IGNITE-23179
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise
>
> The test
> {code:java}
> @Test
> public void testIsNotDistinctFrom() {
> executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
> executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
> null)");
> executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
> executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
> null)");
> String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT
> FROM i3";
> assertQuery(sql)
> .returns(1, 1)
> .returns(2, 2)
> .returns(null, 3)
> .check();
> }
> {code}
> fails with:
> {code:java}
> java.lang.AssertionError: Collections sizes are not equal:
> Expected: [[1, 1], [2, 2], [null, 3]]
> Actual: [[null, 3]]
> {code}
> The is an incirrect numeric types coercion with _IS NOT DISTINCT_. Works is
> the column type would be the same (_INTEGER_).
> Adoption of IGNITE-18163.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23179) Calcite. Wrong numeric type coercion with 'IS DISTINCT FROM'
Vladimir Steshin created IGNITE-23179:
-
Summary: Calcite. Wrong numeric type coercion with 'IS DISTINCT
FROM'
Key: IGNITE-23179
URL: https://issues.apache.org/jira/browse/IGNITE-23179
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
The test
{code:java}
@Test
public void testIsNotDistinctFrom() {
executeSql("CREATE TABLE t1(i1 INTEGER, i2 INTEGER)");
executeSql("INSERT INTO t1 VALUES (1, null), (2, 2), (null, 3), (3,
null)");
executeSql("CREATE TABLE t2(i3 DECIMAL, i4 INTEGER)");
executeSql("INSERT INTO t2 VALUES (1, 1), (2, 2), (null, 3), (4,
null)");
String sql = "SELECT i1, i4 FROM t1 JOIN t2 ON i1 IS NOT DISTINCT FROM
i3";
assertQuery(sql)
.returns(1, 1)
.returns(2, 2)
.returns(null, 3)
.check();
}
{code}
fails with:
{code:java}
java.lang.AssertionError: Collections sizes are not equal:
Expected: [[1, 1], [2, 2], [null, 3]]
Actual: [[null, 3]]
{code}
The is an incirrect numeric types coercion with _IS NOT DISTINCT_. Works is the
column type would be the same (_INTEGER_).
Adoption of IGNITE-18163.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23178) Calcite. Least restrictive type priority DOUBLE over FLOAT
[
https://issues.apache.org/jira/browse/IGNITE-23178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23178:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Calcite. Least restrictive type priority DOUBLE over FLOAT
> --
>
> Key: IGNITE-23178
> URL: https://issues.apache.org/jira/browse/IGNITE-23178
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
>
> Calcite derives least restrictive approximate numeric type by comparing the
> precisions. While _FLOAT_ has the same precision as _DOUBLE_ (currently 15),
> the least restrictive type may variate between them and issue _FLOAT_ instead
> of _DOUBLE_. DOUBLE is more preferable:
> {code:java}
> IgniteTypeFactory#leastRestrictive(List types)
> {code}
> may produce _FLOAT_ when _types_ has a _DOUBLE_.
> Adoption of IGNITE-18556
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23058) Remove snapshot check tasks.
[ https://issues.apache.org/jira/browse/IGNITE-23058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23058: -- Description: Since we have a distributed process for snapshot checks, the snapshot check compute tasks aren't required any more. They should be removed. (was: Since we have a distributed process for snapshot checks, we need no compute tasks for that any more, They should be removed.) > Remove snapshot check tasks. > > > Key: IGNITE-23058 > URL: https://issues.apache.org/jira/browse/IGNITE-23058 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Since we have a distributed process for snapshot checks, the snapshot check > compute tasks aren't required any more. They should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23118) Insufficient backward connection check.
[
https://issues.apache.org/jira/browse/IGNITE-23118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23118:
--
Description:
We do the node status backward check only by socket opening:
{code:java}
ServerImpl#SocketReader#checkConnection(TcpDiscoveryNode node, int timeout):
InetSocketAddress addr = addrs.get(addrIdx.getAndIncrement()):
try (Socket sock = new Socket()) {
if (liveAddrHolder.get() == null) {
sock.connect(addr, perAddrTimeout);
liveAddrHolder.compareAndSet(null, addr);
}
}
{code}
We write no byte and wait for no any trivial response. If JVM stucks GC pause
but accepts socket connection, this check gives a false positive result. This
can issue wrong node leaves the cluster. A node before the hanging one.
Consider:
1) There a cluster with nodes 'A', 'B', 'C'.
2) 'B' delays in GC pause or waits for some threads to stop at safe points.
Its discovery threads are already suspended and do not read or write
messages/responses.
3) 'A' fails to send a message to 'B' and sees the timeout.
4) 'A' connects to 'C', asks to check 'B' and to establish new permanent
cluster connection 'A'->'C' if 'C' cannot check/ping 'B'.
5) 'C' pings 'B', successfully creates connection to it (Socket#connect()).
And closes the socket just after it was opened.
6) 'C' denies establishing a permanent cluster connection with 'A', answers
that 'B' is alive.
7) 'A' tries to connect to 'B' again. Successfully connects to it
(Socket#connect()), but receives no any answer because the JVM of 'B' can only
accept connections, but the reading/writing to socket Ignite's threads are
suspended.
8) 'A' loops in #3 - #7 till reaches `connectionRecoveryTimeout`.
9) 'A' segments, leaves the cluster despite it is alive and is able to
establish a permanent cluster connection to 'C'.
We should either make this check writing something to the socket and waiting
for a response or even remove it at all.
was:
We do the node status backward check only by opening socket:
{code:java}
ServerImpl#SocketReader#checkConnection(TcpDiscoveryNode node, int timeout):
InetSocketAddress addr = addrs.get(addrIdx.getAndIncrement()):
try (Socket sock = new Socket()) {
if (liveAddrHolder.get() == null) {
sock.connect(addr, perAddrTimeout);
liveAddrHolder.compareAndSet(null, addr);
}
}
{code}
We write no byte and wait for no any trivial response. If JVM stucks GC pause
but accepts socket connection, this check gives a false positive result. This
can issue wrong node leaves the cluster. A node before the hanging one.
Consider:
1) There a cluster with nodes 'A', 'B', 'C'.
2) 'B' delays in GC pause or waits for some threads to stop at safe points.
Its discovery threads are already suspended and do not read or write
messages/responses.
3) 'A' fails to send a message to 'B' and sees the timeout.
4) 'A' connects to 'C', asks to check 'B' and to establish new permanent
cluster connection 'A'->'C' if 'C' cannot check/ping 'B'.
5) 'C' pings 'B', successfully creates connection to it (Socket#connect()).
And closes the socket just after it was opened.
6) 'C' denies establishing a permanent cluster connection with 'A', answers
that 'B' is alive.
7) 'A' tries to connect to 'B' again. Successfully connects to it
(Socket#connect()), but receives no any answer because the JVM of 'B' can only
accept connections, but the reading/writing to socket Ignite's threads are
suspended.
8) 'A' loops in #3 - #7 till reaches `connectionRecoveryTimeout`.
9) 'A' segments, leaves the cluster despite it is alive and is able to
establish a permanent cluster connection to 'C'.
We should either make this check writing something to the socket and waiting
for a response or even remove it at all.
> Insufficient backward connection check.
> ---
>
> Key: IGNITE-23118
> URL: https://issues.apache.org/jira/browse/IGNITE-23118
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> We do the node status backward check only by socket opening:
> {code:java}
> ServerImpl#SocketReader#checkConnection(TcpDiscoveryNode node, int timeout):
> InetSocketAddress addr = addrs.get(addrIdx.getAndIncrement()):
> try (Socket sock = new Socket()) {
> if (liveAddrHolder.get() == null) {
> sock.connect(addr, perAddrTimeout);
> liveAddrHolder.compareAndSet(null, addr);
> }
> }
> {code}
> We write no byte and wait for no any trivial response. If JVM stucks GC pause
> but accepts socket connection, this check gives a false positive result. This
> can issue wrong node leaves the cluster. A node before the hanging one.
> Consider:
> 1) There a cluster with nodes 'A', 'B', 'C'.
>
[jira] [Updated] (IGNITE-23118) Insufficient backward connection check.
[
https://issues.apache.org/jira/browse/IGNITE-23118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23118:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Insufficient backward connection check.
> ---
>
> Key: IGNITE-23118
> URL: https://issues.apache.org/jira/browse/IGNITE-23118
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
>
> We do the node status backward check only by opening socket:
> {code:java}
> ServerImpl#SocketReader#checkConnection(TcpDiscoveryNode node, int timeout):
> InetSocketAddress addr = addrs.get(addrIdx.getAndIncrement()):
> try (Socket sock = new Socket()) {
> if (liveAddrHolder.get() == null) {
> sock.connect(addr, perAddrTimeout);
> liveAddrHolder.compareAndSet(null, addr);
> }
> }
> {code}
> We write no byte and wait for no any trivial response. If JVM stucks GC pause
> but accepts socket connection, this check gives a false positive result. This
> can issue wrong node leaves the cluster. A node before the hanging one.
> Consider:
> 1) There a cluster with nodes 'A', 'B', 'C'.
> 2) 'B' delays in GC pause or waits for some threads to stop at safe
> points. Its discovery threads are already suspended and do not read or write
> messages/responses.
> 3) 'A' fails to send a message to 'B' and sees the timeout.
> 4) 'A' connects to 'C', asks to check 'B' and to establish new permanent
> cluster connection 'A'->'C' if 'C' cannot check/ping 'B'.
> 5) 'C' pings 'B', successfully creates connection to it
> (Socket#connect()). And closes the socket just after it was opened.
> 6) 'C' denies establishing a permanent cluster connection with 'A',
> answers that 'B' is alive.
> 7) 'A' tries to connect to 'B' again. Successfully connects to it
> (Socket#connect()), but receives no any answer because the JVM of 'B' can
> only accept connections, but the reading/writing to socket Ignite's threads
> are suspended.
> 8) 'A' loops in #3 - #7 till reaches `connectionRecoveryTimeout`.
> 9) 'A' segments, leaves the cluster despite it is alive and is able to
> establish a permanent cluster connection to 'C'.
> We should either make this check writing something to the socket and waiting
> for a response or even remove it at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23118) Insufficient backward connection check.
[
https://issues.apache.org/jira/browse/IGNITE-23118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23118:
--
Labels: ise (was: )
> Insufficient backward connection check.
> ---
>
> Key: IGNITE-23118
> URL: https://issues.apache.org/jira/browse/IGNITE-23118
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> We do the node status backward check only by opening socket:
> {code:java}
> ServerImpl#SocketReader#checkConnection(TcpDiscoveryNode node, int timeout):
> InetSocketAddress addr = addrs.get(addrIdx.getAndIncrement()):
> try (Socket sock = new Socket()) {
> if (liveAddrHolder.get() == null) {
> sock.connect(addr, perAddrTimeout);
> liveAddrHolder.compareAndSet(null, addr);
> }
> }
> {code}
> We write no byte and wait for no any trivial response. If JVM stucks GC pause
> but accepts socket connection, this check gives a false positive result. This
> can issue wrong node leaves the cluster. A node before the hanging one.
> Consider:
> 1) There a cluster with nodes 'A', 'B', 'C'.
> 2) 'B' delays in GC pause or waits for some threads to stop at safe
> points. Its discovery threads are already suspended and do not read or write
> messages/responses.
> 3) 'A' fails to send a message to 'B' and sees the timeout.
> 4) 'A' connects to 'C', asks to check 'B' and to establish new permanent
> cluster connection 'A'->'C' if 'C' cannot check/ping 'B'.
> 5) 'C' pings 'B', successfully creates connection to it
> (Socket#connect()). And closes the socket just after it was opened.
> 6) 'C' denies establishing a permanent cluster connection with 'A',
> answers that 'B' is alive.
> 7) 'A' tries to connect to 'B' again. Successfully connects to it
> (Socket#connect()), but receives no any answer because the JVM of 'B' can
> only accept connections, but the reading/writing to socket Ignite's threads
> are suspended.
> 8) 'A' loops in #3 - #7 till reaches `connectionRecoveryTimeout`.
> 9) 'A' segments, leaves the cluster despite it is alive and is able to
> establish a permanent cluster connection to 'C'.
> We should either make this check writing something to the socket and waiting
> for a response or even remove it at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23118) Insufficient backward connection check.
Vladimir Steshin created IGNITE-23118:
-
Summary: Insufficient backward connection check.
Key: IGNITE-23118
URL: https://issues.apache.org/jira/browse/IGNITE-23118
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
We do the node status backward check only by opening socket:
{code:java}
ServerImpl#SocketReader#checkConnection(TcpDiscoveryNode node, int timeout):
InetSocketAddress addr = addrs.get(addrIdx.getAndIncrement()):
try (Socket sock = new Socket()) {
if (liveAddrHolder.get() == null) {
sock.connect(addr, perAddrTimeout);
liveAddrHolder.compareAndSet(null, addr);
}
}
{code}
We write no byte and wait for no any trivial response. If JVM stucks GC pause
but accepts socket connection, this check gives a false positive result. This
can issue wrong node leaves the cluster. A node before the hanging one.
Consider:
1) There a cluster with nodes 'A', 'B', 'C'.
2) 'B' delays in GC pause or waits for some threads to stop at safe points.
Its discovery threads are already suspended and do not read or write
messages/responses.
3) 'A' fails to send a message to 'B' and sees the timeout.
4) 'A' connects to 'C', asks to check 'B' and to establish new permanent
cluster connection 'A'->'C' if 'C' cannot check/ping 'B'.
5) 'C' pings 'B', successfully creates connection to it (Socket#connect()).
And closes the socket just after it was opened.
6) 'C' denies establishing a permanent cluster connection with 'A', answers
that 'B' is alive.
7) 'A' tries to connect to 'B' again. Successfully connects to it
(Socket#connect()), but receives no any answer because the JVM of 'B' can only
accept connections, but the reading/writing to socket Ignite's threads are
suspended.
8) 'A' loops in #3 - #7 till reaches `connectionRecoveryTimeout`.
9) 'A' segments, leaves the cluster despite it is alive and is able to
establish a permanent cluster connection to 'C'.
We should either make this check writing something to the socket and waiting
for a response or even remove it at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23112) Calcite. Allow grouping by alias and ordinal value.
[ https://issues.apache.org/jira/browse/IGNITE-23112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23112: -- Labels: calcite ise (was: calcite ise sql) > Calcite. Allow grouping by alias and ordinal value. > --- > > Key: IGNITE-23112 > URL: https://issues.apache.org/jira/browse/IGNITE-23112 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: calcite, ise > > Adoption of AI3's IGNITE-18212. `GROUP BY` should be allowed to work with > aliases and ordinal values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23112) Calcite. Allow grouping by alias and ordinal value.
Vladimir Steshin created IGNITE-23112: - Summary: Calcite. Allow grouping by alias and ordinal value. Key: IGNITE-23112 URL: https://issues.apache.org/jira/browse/IGNITE-23112 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin Adoption of AI3's IGNITE-18212. `GROUP BY` should be allowed to work with aliases and ordinal values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23112) Calcite. Allow grouping by alias and ordinal value.
[ https://issues.apache.org/jira/browse/IGNITE-23112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23112: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Calcite. Allow grouping by alias and ordinal value. > --- > > Key: IGNITE-23112 > URL: https://issues.apache.org/jira/browse/IGNITE-23112 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > Adoption of AI3's IGNITE-18212. `GROUP BY` should be allowed to work with > aliases and ordinal values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23112) Calcite. Allow grouping by alias and ordinal value.
[ https://issues.apache.org/jira/browse/IGNITE-23112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23112: -- Labels: calcite ise sql (was: ) > Calcite. Allow grouping by alias and ordinal value. > --- > > Key: IGNITE-23112 > URL: https://issues.apache.org/jira/browse/IGNITE-23112 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: calcite, ise, sql > > Adoption of AI3's IGNITE-18212. `GROUP BY` should be allowed to work with > aliases and ordinal values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22662) Snapshot check as distributed process
[ https://issues.apache.org/jira/browse/IGNITE-22662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22662: -- Ignite Flags: Docs Required,Release Notes Required (was: Release Notes Required) > Snapshot check as distributed process > - > > Key: IGNITE-22662 > URL: https://issues.apache.org/jira/browse/IGNITE-22662 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Time Spent: 11h 50m > Remaining Estimate: 0h > > The snapshot validation should be a distributed process. Currently, the > validation is a computation tasks/jobs. Stopping or declining 2 concurrent > 'heavy' checks aren't handy. Also, snapshot check status or snapshot check > metrics are simpler when the validation is only one per snapshot and > implemented similar to snapshot creation or restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23057) Move incremental snapshot check to the distributed process.
[ https://issues.apache.org/jira/browse/IGNITE-23057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23057: -- Description: Check of incremental snapshot should be moved to the distributed process too. (was: Check of incremental snapshot should be moved to the distributed process.) Summary: Move incremental snapshot check to the distributed process. (was: Move check of Incremental to the distributed process.) > Move incremental snapshot check to the distributed process. > --- > > Key: IGNITE-23057 > URL: https://issues.apache.org/jira/browse/IGNITE-23057 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > Check of incremental snapshot should be moved to the distributed process too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23058) Remove snapshot check tasks.
[ https://issues.apache.org/jira/browse/IGNITE-23058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23058: -- Labels: ise (was: ) > Remove snapshot check tasks. > > > Key: IGNITE-23058 > URL: https://issues.apache.org/jira/browse/IGNITE-23058 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > Since we have a distributed process for snapshot checks, we need no compute > tasks for that any more, They should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23058) Remove snapshot check tasks.
[ https://issues.apache.org/jira/browse/IGNITE-23058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23058: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Remove snapshot check tasks. > > > Key: IGNITE-23058 > URL: https://issues.apache.org/jira/browse/IGNITE-23058 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > > Since we have a distributed process for snapshot checks, we need no compute > tasks for that any more, They should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23058) Remove snapshot check tasks.
Vladimir Steshin created IGNITE-23058: - Summary: Remove snapshot check tasks. Key: IGNITE-23058 URL: https://issues.apache.org/jira/browse/IGNITE-23058 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Since we have a distributed process for snapshot checks, we need no compute tasks for that any more, They should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23057) Move check of Incremental to the distributed process.
[ https://issues.apache.org/jira/browse/IGNITE-23057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23057: -- Issue Type: Improvement (was: Bug) > Move check of Incremental to the distributed process. > - > > Key: IGNITE-23057 > URL: https://issues.apache.org/jira/browse/IGNITE-23057 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > Check of incremental snapshot should be moved to the distributed process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23057) Move check of Incremental to the distributed process.
Vladimir Steshin created IGNITE-23057: - Summary: Move check of Incremental to the distributed process. Key: IGNITE-23057 URL: https://issues.apache.org/jira/browse/IGNITE-23057 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin Check of incremental snapshot should be moved to the distributed process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23057) Move check of Incremental to the distributed process.
[ https://issues.apache.org/jira/browse/IGNITE-23057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23057: -- Labels: ise (was: ) > Move check of Incremental to the distributed process. > - > > Key: IGNITE-23057 > URL: https://issues.apache.org/jira/browse/IGNITE-23057 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > > Check of incremental snapshot should be moved to the distributed process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23057) Move check of Incremental to the distributed process.
[ https://issues.apache.org/jira/browse/IGNITE-23057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-23057: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Move check of Incremental to the distributed process. > - > > Key: IGNITE-23057 > URL: https://issues.apache.org/jira/browse/IGNITE-23057 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > Check of incremental snapshot should be moved to the distributed process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22992) Calcite engine. Refactor BaseQueryContext.Builder
[ https://issues.apache.org/jira/browse/IGNITE-22992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22992: -- Labels: calcite ise (was: calcite sbt) > Calcite engine. Refactor BaseQueryContext.Builder > - > > Key: IGNITE-22992 > URL: https://issues.apache.org/jira/browse/IGNITE-22992 > Project: Ignite > Issue Type: Task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, ise > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently, there are several usages of > BaseQueryContext.Builder#frameworkConfig in code, which build new > FrameworkConfig instance only to provide default schema. These usages can be > simplified. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22992) Calcite engine. Refactor BaseQueryContext.Builder
[ https://issues.apache.org/jira/browse/IGNITE-22992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22992: -- Labels: calcite sbt (was: ) > Calcite engine. Refactor BaseQueryContext.Builder > - > > Key: IGNITE-22992 > URL: https://issues.apache.org/jira/browse/IGNITE-22992 > Project: Ignite > Issue Type: Task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, sbt > Time Spent: 20m > Remaining Estimate: 0h > > Currently, there are several usages of > BaseQueryContext.Builder#frameworkConfig in code, which build new > FrameworkConfig instance only to provide default schema. These usages can be > simplified. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22717) Calcite engine. User defined SQL views
[
https://issues.apache.org/jira/browse/IGNITE-22717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22717:
--
Labels: calcite ise sql (was: ise)
> Calcite engine. User defined SQL views
> --
>
> Key: IGNITE-22717
> URL: https://issues.apache.org/jira/browse/IGNITE-22717
> Project: Ignite
> Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise, sql
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> A view is a virtual table whose contents are defined by a query. It's a
> convenient mechanism to simplify queries.
> Views are supported by many databases. Calcite Framework also supports user
> defined views (see {{ViewTable.viewMacro}}) and we can add support of views
> to Calcite based SQL engine to Ignite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872383#comment-17872383
]
Vladimir Steshin commented on IGNITE-22967:
---
The offset (_LogicalSort_ with the _offset_) is removed in
_SqlToRelConverter#convertSelectImpl(Blackboard bb, SqlSelect select)_:
{code:java}
// Semantics example. Given the view definition
// CREATE VIEW v2 AS SELECT * FROM t ORDER BY x LIMIT 10
// we would never remove the ORDER BY, because "ORDER BY ... LIMIT" is about
// semantics. It is not a 'pure order'.
if (RelOptUtil.isPureOrder(castNonNull(bb.root))
&& config.isRemoveSortInSubQuery()) {
// Remove the Sort if the view is at the top level. Also remove the Sort
// if there are other nodes, which will cause the view to be in the
// sub-query.
if (!bb.top
|| validator().isAggregate(select)
|| select.isDistinct()
|| select.hasOrderBy()
|| select.getFetch() != null
|| select.getOffset() != null) {
bb.setRoot(castNonNull(bb.root).getInput(0), true);
}
}
{code}
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise, sql
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEntity()
> .setTableName("TEST_REPL")
> .setKeyType(Integer.class.getName())
> .setValueType(String.class.getName())
> .setKeyFieldName("id")
> .setValueFieldName("val")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("val", String.class.getName(), null);
> return super.getConfiguration(igniteInstanceName)
> .setCacheConfiguration(
> new CacheConfiguration<>(eRepl.getTableName())
> .setCacheMode(CacheMode.REPLICATED)
> .setQueryEntities(singletonList(eRepl))
> .setSqlSchema("PUBLIC"));
> }
> }
> {code}
> Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or
> `ORDER BY` fixes.
> Plan without the `ORDER BY`:
> {code:java}
> IgniteUnionAll(all=[true])
> IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
> filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
> ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
> IgniteLimit(offset=[1])
> IgniteLimit(offset=[2])
> IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
> {code}
> Plan with the `ORDER BY`
> {code:java}
> IgniteUnionAll(all=[true])
> IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
> filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
> ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
> IgniteLimit(offset=[2])
> IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Description:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
Plan without the `ORDER BY`:
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[1])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
Plan with the `ORDER BY`
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
was:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
Plan without the `ORDER`:
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[1])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
Plan with the `ORDER`
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Description:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
Plan without the order:
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[1])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
Plan with the order
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
was:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise, sql
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEnti
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Description:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
Plan without the `ORDER`:
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[1])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
Plan with the `ORDER`
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
was:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
Plan without the order:
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[1])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
Plan with the order
{code:java}
IgniteUnionAll(all=[true])
IgniteIndexScan(table=[[PUBLIC, TEST_REPL]], index=[_key_PK_proxy],
filters=[=($t0, 2)], requiredColumns=[{2}], searchBounds=[[null, null,
ExactBounds [bound=2], null]], collation=[[2 ASC-nulls-first]])
IgniteLimit(offset=[2])
IgniteTableScan(table=[[PUBLIC, TEST_REPL]], requiredColumns=[{2}])
{code}
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assi
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Description:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
was:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise, sql
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEntity()
> .setTableName("TEST_REPL")
> .setKeyType(Integer.class.getName())
> .setValueType(String.class.getName())
> .setKeyFieldName("id")
> .setValueFieldName("val")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("val", String.class.getName(), null);
> return super.getConfiguration(igniteInstanceName)
> .setCacheConfiguration(
> new CacheConfiguration<>(eRepl.getTableName())
> .setCacheMode(CacheMode.REPLICATED)
> .setQueryEntities(singletonList(eRepl))
> .setSqlSchema("PUBLIC"));
> }
> }
> {code}
> Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise, sql
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEntity()
> .setTableName("TEST_REPL")
> .setKeyType(Integer.class.getName())
> .setValueType(String.class.getName())
> .setKeyFieldName("id")
> .setValueFieldName("val")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("val", String.class.getName(), null);
> return super.getConfiguration(igniteInstanceName)
> .setCacheConfiguration(
> new CacheConfiguration<>(eRepl.getTableName())
> .setCacheMode(CacheMode.REPLICATED)
> .setQueryEntities(singletonList(eRepl))
> .setSqlSchema("PUBLIC"));
> }
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> }
> {code}
> Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or
> `ORDER BY` fixes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Description:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or `ORDER
BY` fixes.
was:
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing the `UNION` or `ORDER
BY` fixes.
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise, sql
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEntity()
> .setTableName("TEST_REPL")
> .setKeyType(Integer.class.getName())
> .setValueType(String.class.getName())
> .setKeyFieldName("id")
> .setValueFieldName("val")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("val", String.class.getName(), null);
> return super.getConfiguration(igniteInstanceName)
> .setCacheConfiguration(
> new CacheConfiguration<>(eRepl.getTableName())
> .setCacheMode(CacheMode.REPLICATED)
> .setQueryEntities(singletonList(eRepl))
> .setSqlSchema("PUBLIC"));
> }
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> }
> {code}
> Gives the result [2, 3, 4] instead of [2, 4]. Removing any of `UNION` or
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Labels: calcite ise sql (was: calcite ise)
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise, sql
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEntity()
> .setTableName("TEST_REPL")
> .setKeyType(Integer.class.getName())
> .setValueType(String.class.getName())
> .setKeyFieldName("id")
> .setValueFieldName("val")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("val", String.class.getName(), null);
> return super.getConfiguration(igniteInstanceName)
> .setCacheConfiguration(
> new CacheConfiguration<>(eRepl.getTableName())
> .setCacheMode(CacheMode.REPLICATED)
> .setQueryEntities(singletonList(eRepl))
> .setSqlSchema("PUBLIC"));
> }
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> }
> {code}
> Gives the result [2, 3, 4] instead of [2, 4]. Removing the `UNION` or `ORDER
> BY` fixes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
Vladimir Steshin created IGNITE-22967:
-
Summary: Incorrect SQL result with UNION, ORDER BY and OFFSET
Key: IGNITE-22967
URL: https://issues.apache.org/jira/browse/IGNITE-22967
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
Test
{code:java}
public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
QueryEntity eRepl = new QueryEntity()
.setTableName("TEST_REPL")
.setKeyType(Integer.class.getName())
.setValueType(String.class.getName())
.setKeyFieldName("id")
.setValueFieldName("val")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("val", String.class.getName(), null);
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(
new CacheConfiguration<>(eRepl.getTableName())
.setCacheMode(CacheMode.REPLICATED)
.setQueryEntities(singletonList(eRepl))
.setSqlSchema("PUBLIC"));
}
/** */
@Test
public void testLimitOffsetWithNestedUnion() {
sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
'd')");
assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
"SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET 2)
order by id OFFSET 1)"
).returns(2).returns(4).check();
}
}
{code}
Gives the result [2, 3, 4] instead of [2, 4]. Removing the `UNION` or `ORDER
BY` fixes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22967) Incorrect SQL result with UNION, ORDER BY and OFFSET
[
https://issues.apache.org/jira/browse/IGNITE-22967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22967:
--
Labels: calcite ise (was: )
> Incorrect SQL result with UNION, ORDER BY and OFFSET
>
>
> Key: IGNITE-22967
> URL: https://issues.apache.org/jira/browse/IGNITE-22967
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, ise
>
> Test
> {code:java}
> public class LimitOffsetIntegrationTest extends AbstractBasicIntegrationTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> QueryEntity eRepl = new QueryEntity()
> .setTableName("TEST_REPL")
> .setKeyType(Integer.class.getName())
> .setValueType(String.class.getName())
> .setKeyFieldName("id")
> .setValueFieldName("val")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("val", String.class.getName(), null);
> return super.getConfiguration(igniteInstanceName)
> .setCacheConfiguration(
> new CacheConfiguration<>(eRepl.getTableName())
> .setCacheMode(CacheMode.REPLICATED)
> .setQueryEntities(singletonList(eRepl))
> .setSqlSchema("PUBLIC"));
> }
> /** */
> @Test
> public void testLimitOffsetWithNestedUnion() {
> sql("INSERT into TEST_REPL VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4,
> 'd')");
> assertQuery("(SELECT id FROM TEST_REPL WHERE id = 2) UNION ALL " +
> "SELECT id FROM (select id from (SELECT id FROM TEST_REPL OFFSET
> 2) order by id OFFSET 1)"
> ).returns(2).returns(4).check();
> }
> }
> {code}
> Gives the result [2, 3, 4] instead of [2, 4]. Removing the `UNION` or `ORDER
> BY` fixes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22662) Snapshot check as distributed process
[ https://issues.apache.org/jira/browse/IGNITE-22662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22662: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Snapshot check as distributed process > - > > Key: IGNITE-22662 > URL: https://issues.apache.org/jira/browse/IGNITE-22662 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Time Spent: 7.5h > Remaining Estimate: 0h > > The snapshot validation should be a distributed process. Currently, the > validation is a computation tasks/jobs. Stopping or declining 2 concurrent > 'heavy' checks aren't handy. Also, snapshot check status or snapshot check > metrics are simpler when the validation is only one per snapshot and > implemented similar to snapshot creation or restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22662) Snapshot check as distributed process
[ https://issues.apache.org/jira/browse/IGNITE-22662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-22662: - Assignee: Vladimir Steshin > Snapshot check as distributed process > - > > Key: IGNITE-22662 > URL: https://issues.apache.org/jira/browse/IGNITE-22662 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Time Spent: 4h 50m > Remaining Estimate: 0h > > The snapshot validation should be a distributed process. Currently, the > validation is a computation tasks/jobs. Stopping or declining 2 concurrent > 'heavy' checks aren't handy. Also, snapshot check status or snapshot check > metrics are simpler when the validation is only one per snapshot and > implemented similar to snapshot creation or restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-22776:
-
Assignee: Vladimir Steshin
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Attachments: StatisticsObsolescenceTest.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends to update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere. But
> {code:java}
> partStat.rowCount()
> {code}
> is 0 at the beginning. This is why the statistic is calculated once.
> A workaroung might be setting the threshold to a negative value:
> {code:java}
> ANALYZE MY_TABLE WITH MAX_CHANGED_PARTITION_ROWS_PERCENT=-1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends to update with CRUD only once. Despite the
obsolescence threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
A workaroung might be setting the threshold to a negative value:
{code:java}
ANALYZE MY_TABLE WITH MAX_CHANGED_PARTITION_ROWS_PERCENT=-1
{code}
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
A workaroung might be setting the threshold to a negative value:
{code:java}
ANALYZE MY_TABLE WITH MAX_CHANGED_PARTITION_ROWS_PERCENT=-1
{code}
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'stat
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
A workaroung might be setting the threshold to a negative value:
{code:java}
ANALYZE MY_TABLE WITH MAX_CHANGED_PARTITION_ROWS_PERCENT=-1
{code}
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Des
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Attachment: StatisticsObsolescenceTest.java
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere. But
> {code:java}
> partStat.rowCount()
> {code}
> is 0 at the beginning. This is why the statistic is calculated once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Attachment: (was: StatisticsObsolescenceTest.java)
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere. But
> {code:java}
> partStat.rowCount()
> {code}
> is 0 at the beginning. This is why the statistic is calculated once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsole
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`long ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsole
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated once.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated one.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 se
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere. But
{code:java}
partStat.rowCount()
{code}
is 0 at the beginning. This is why the statistic is calculated one.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
>
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despite the obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despitethe obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000,
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends update with CRUD only once. Despitethe obsolescence
threshold, by default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends not to get updated with CRUD even there is an
obsolescence threshold. By default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despitethe obsolescence
> threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Affects Version/s: 2.15
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends not to get updated with CRUD even there is an
> obsolescence threshold. By default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22776) SQL table statistic is updated only once.
Vladimir Steshin created IGNITE-22776:
-
Summary: SQL table statistic is updated only once.
Key: IGNITE-22776
URL: https://issues.apache.org/jira/browse/IGNITE-22776
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control. Sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:java}
ANALYZE MY_TABLE
{code}
But table statistic tends not to be update with CRUD even there is an
obsolescence threshold. By default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Regarding my research, partition statistics obsolescence is checked every 60
seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
The problem seems to reside in
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where `v.modified()` (`long ObjectPartitionStatisticsObsolescence#modified()`)
is always 0. never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Labels: ise (was: )
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere. But
> {code:java}
> partStat.rowCount()
> {code}
> is 0 at the beginning. This is why the statistic is calculated once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Attachment: StatisticsObsolescenceTest.java
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments: StatisticsObsolescenceTest.java
>
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends update with CRUD only once. Despite the
> obsolescence threshold, by default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere. But
> {code:java}
> partStat.rowCount()
> {code}
> is 0 at the beginning. This is why the statistic is calculated once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends not to get updated with CRUD even there is an
obsolescence threshold. By default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where never updates.
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control. Sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:java}
ANALYZE MY_TABLE
{code}
But table statistic tends not to be update with CRUD even there is an
obsolescence threshold. By default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Regarding my research, partition statistics obsolescence is checked every 60
seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
The problem seems to reside in
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where `v.modified()` (`long ObjectPartitionStatisticsObsolescence#modified()`)
is always 0. never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends not to get updated with CRUD even there is an
> obsolescence threshold. By default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENC
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Description:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends not to get updated with CRUD even there is an
obsolescence threshold. By default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0, never updates. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
was:
To build a better plan, H2 can rely on the statistics. We can enable it with
{code:java}
control.sh --property set --name 'statistics. Usage. State' --val 'ON'
{code}
and
{code:sql}
ANALYZE MY_TABLE
{code}
But table statistic tends not to get updated with CRUD even there is an
obsolescence threshold. By default
{code:java}
int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
{code}
Partition statistics obsolescence is checked every 60 seconds:
{code:java}
int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
if (serverNode) {
obsolescenceSchedule = ctx.timeout().schedule(() -> {
obsolescenceBusyExecutor.execute(() -> processObsolescence());
}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
}
{code}
Regarding my research, the problem is within
{code:java}
private Set
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
StatisticsObjectConfiguration cfg,
IntMap parts
) {
Set res = new HashSet<>();
parts.forEach((k, v) -> {
ObjectPartitionStatisticsImpl partStat =
statsRepos.getLocalPartitionStatistics(cfg.key(), k);
if (partStat == null || partStat.rowCount() == 0 ||
(double)v.modified() * 100 / partStat.rowCount() >
cfg.maxPartitionObsolescencePercent())
res.add(k);
});
// Will add even empty list of partitions to recollect just to force
obsolescence info to be stored.
return res;
}
{code}
Where never updates.
{code:java}
v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
{code}
is always 0. Probably because
{code:java}
IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
schemaName, String objName, int partId, byte[] keyBytes)
{code}
is called nowhere.
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends not to get updated with CRUD even there is an
> obsolescence threshold. By default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESC
[jira] [Updated] (IGNITE-22776) SQL table statistic is updated only once.
[
https://issues.apache.org/jira/browse/IGNITE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22776:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> SQL table statistic is updated only once.
> -
>
> Key: IGNITE-22776
> URL: https://issues.apache.org/jira/browse/IGNITE-22776
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
>
> To build a better plan, H2 can rely on the statistics. We can enable it with
> {code:java}
> control.sh --property set --name 'statistics. Usage. State' --val 'ON'
> {code}
> and
> {code:sql}
> ANALYZE MY_TABLE
> {code}
> But table statistic tends not to get updated with CRUD even there is an
> obsolescence threshold. By default
> {code:java}
> int StatisticsObjectConfiguration#DEFAULT_OBSOLESCENCE_MAX_PERCENT = 15;
> {code}
> Partition statistics obsolescence is checked every 60 seconds:
> {code:java}
> int IgniteStatisticsManagerImpl#OBSOLESCENCE_INTERVAL = 60;
> if (serverNode) {
>obsolescenceSchedule = ctx.timeout().schedule(() -> {
> obsolescenceBusyExecutor.execute(() -> processObsolescence());
>}, OBSOLESCENCE_INTERVAL * 1000, OBSOLESCENCE_INTERVAL * 1000);
> }
> {code}
> Regarding my research, the problem is within
> {code:java}
> private Set
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions(
> StatisticsObjectConfiguration cfg,
> IntMap parts
> ) {
> Set res = new HashSet<>();
> parts.forEach((k, v) -> {
> ObjectPartitionStatisticsImpl partStat =
> statsRepos.getLocalPartitionStatistics(cfg.key(), k);
> if (partStat == null || partStat.rowCount() == 0 ||
> (double)v.modified() * 100 / partStat.rowCount() >
> cfg.maxPartitionObsolescencePercent())
> res.add(k);
> });
> // Will add even empty list of partitions to recollect just to force
> obsolescence info to be stored.
> return res;
> }
> {code}
> Where
> {code:java}
> v.modified() (`ong ObjectPartitionStatisticsObsolescence#modified())
> {code}
> is always 0, never updates. Probably because
> {code:java}
> IgniteStatisticsManagerImpl#calculateObsolescencedPartitions#onRowUpdated(String
> schemaName, String objName, int partId, byte[] keyBytes)
> {code}
> is called nowhere.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
[ https://issues.apache.org/jira/browse/IGNITE-22704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-22704. --- Release Note: Irrelevant Resolution: Won't Fix > Missing '--only-primary' argument of snapshot creation command > -- > > Key: IGNITE-22704 > URL: https://issues.apache.org/jira/browse/IGNITE-22704 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The command "_control.sh --snapshot create --only-primary_" might create an > only-primaries snapshot. But the argument '--only-primary' is skipped now. > Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
[ https://issues.apache.org/jira/browse/IGNITE-22704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22704: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Missing '--only-primary' argument of snapshot creation command > -- > > Key: IGNITE-22704 > URL: https://issues.apache.org/jira/browse/IGNITE-22704 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > The command "_control.sh --snapshot create --only-primary_" might create an > only-primaries snapshot. But the argument '--only-primary' is skipped now. > Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
[ https://issues.apache.org/jira/browse/IGNITE-22704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin closed IGNITE-22704. - > Missing '--only-primary' argument of snapshot creation command > -- > > Key: IGNITE-22704 > URL: https://issues.apache.org/jira/browse/IGNITE-22704 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > The command "_control.sh --snapshot create --only-primary_" might create an > only-primaries snapshot. But the argument '--only-primary' is skipped now. > Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
[ https://issues.apache.org/jira/browse/IGNITE-22704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22704: -- Priority: Minor (was: Major) > Missing '--only-primary' argument of snapshot creation command > -- > > Key: IGNITE-22704 > URL: https://issues.apache.org/jira/browse/IGNITE-22704 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > The command "_control.sh --snapshot create --only-primary_" might create an > only-primaries snapshot. But the argument '--only-primary' is skipped now. > Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
[ https://issues.apache.org/jira/browse/IGNITE-22704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22704: -- Description: The command "_control.sh --snapshot create --only-primary_" might create an only-primaries snapshot. But the argument '--only-primary' is skipped now. Also, there is no test for that. (was: The command `control.sh --snapshot create --only-primary` might create an only-primaries snapshot. But the argument '--only-primary' is skipped now. Also, there is no test for that.) > Missing '--only-primary' argument of snapshot creation command > -- > > Key: IGNITE-22704 > URL: https://issues.apache.org/jira/browse/IGNITE-22704 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The command "_control.sh --snapshot create --only-primary_" might create an > only-primaries snapshot. But the argument '--only-primary' is skipped now. > Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
[ https://issues.apache.org/jira/browse/IGNITE-22704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22704: -- Description: The command `control.sh --snapshot create --only-primary` might create an only-primaries snapshot. But the argument '--only-primary' is skipped now. Also, there is no test for that. (was: The command 'control.sh --snapshot create --only-primary'' might create only-primaries snapshot. But the argument '--only-primary' is skipped now. Also, there is no test for that.) > Missing '--only-primary' argument of snapshot creation command > -- > > Key: IGNITE-22704 > URL: https://issues.apache.org/jira/browse/IGNITE-22704 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The command `control.sh --snapshot create --only-primary` might create an > only-primaries snapshot. But the argument '--only-primary' is skipped now. > Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22704) Missing '--only-primary' argument of snapshot creation command
Vladimir Steshin created IGNITE-22704: - Summary: Missing '--only-primary' argument of snapshot creation command Key: IGNITE-22704 URL: https://issues.apache.org/jira/browse/IGNITE-22704 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin The command 'control.sh --snapshot create --only-primary'' might create only-primaries snapshot. But the argument '--only-primary' is skipped now. Also, there is no test for that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22662) Snapshot check as distributed process
[ https://issues.apache.org/jira/browse/IGNITE-22662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22662: -- Labels: ise (was: ) > Snapshot check as distributed process > - > > Key: IGNITE-22662 > URL: https://issues.apache.org/jira/browse/IGNITE-22662 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > The snapshot validation should be a distributed process. Currently, the > validation is a computation tasks/jobs. Stopping or declining 2 concurrent > 'heavy' checks aren't handy. Also, snapshot check status or snapshot check > metrics are simpler when the validation is only one per snapshot and > implemented similar to snapshot creation or restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22662) Snapshot check as distributed process
Vladimir Steshin created IGNITE-22662: - Summary: Snapshot check as distributed process Key: IGNITE-22662 URL: https://issues.apache.org/jira/browse/IGNITE-22662 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin The snapshot validation should be a distributed process. Currently, the validation is a computation tasks/jobs. Stopping or declining 2 concurrent 'heavy' checks aren't handy. Also, snapshot check status or snapshot check metrics are simpler when the validation is only one per snapshot and implemented similar to snapshot creation or restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16989) Annoying "Failed to ping node" warn messages in logs.
[ https://issues.apache.org/jira/browse/IGNITE-16989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16989: -- Description: >From user list [1]. It seems there is a present annoying uninformative message >in the logs. We might need to print only one of such a kind of messages and >wrap others into trace or debug severity. [1] https://lists.apache.org/thread/1mkng62pco1nsjtdgm881m5ny9v3rogd [~vladsz83] fyi too. was: >From user list [1], seems there is present annoying uninformative message in >logs, possible we neet to print only one of such a kind of messages and wrap >others into trace or debug severity? [1] https://lists.apache.org/thread/1mkng62pco1nsjtdgm881m5ny9v3rogd [~vladsz83] fyi too. > Annoying "Failed to ping node" warn messages in logs. > - > > Key: IGNITE-16989 > URL: https://issues.apache.org/jira/browse/IGNITE-16989 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.13 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ise, storage-engine > > From user list [1]. It seems there is a present annoying uninformative > message in the logs. We might need to print only one of such a kind of > messages and wrap others into trace or debug severity. > [1] https://lists.apache.org/thread/1mkng62pco1nsjtdgm881m5ny9v3rogd > [~vladsz83] fyi too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22412) Unify snapshot validation jobs
[ https://issues.apache.org/jira/browse/IGNITE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22412: -- Summary: Unify snapshot validation jobs (was: Unify snapshot validation tasks) > Unify snapshot validation jobs > -- > > Key: IGNITE-22412 > URL: https://issues.apache.org/jira/browse/IGNITE-22412 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.17 > > > We should bring some AbtsractSnapshotValidationJob into the task. > VerifyIncrementalSnapshotJob, SnapshotHandlerRestoreJob and > VerifySnapshotPartitionsJob have many code duplications. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22412) Unify snapshot validation tasks
Vladimir Steshin created IGNITE-22412: - Summary: Unify snapshot validation tasks Key: IGNITE-22412 URL: https://issues.apache.org/jira/browse/IGNITE-22412 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin We should bring some AbtsractSnapshotValidationJob into the task. VerifyIncrementalSnapshotJob, SnapshotHandlerRestoreJob and VerifySnapshotPartitionsJob have many code duplications. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22412) Unify snapshot validation tasks
[ https://issues.apache.org/jira/browse/IGNITE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22412: -- Labels: ise (was: ) > Unify snapshot validation tasks > --- > > Key: IGNITE-22412 > URL: https://issues.apache.org/jira/browse/IGNITE-22412 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.17 > > > We should bring some AbtsractSnapshotValidationJob into the task. > VerifyIncrementalSnapshotJob, SnapshotHandlerRestoreJob and > VerifySnapshotPartitionsJob have many code duplications. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22412) Unify snapshot validation tasks
[ https://issues.apache.org/jira/browse/IGNITE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22412: -- Fix Version/s: 2.17 > Unify snapshot validation tasks > --- > > Key: IGNITE-22412 > URL: https://issues.apache.org/jira/browse/IGNITE-22412 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.17 > > > We should bring some AbtsractSnapshotValidationJob into the task. > VerifyIncrementalSnapshotJob, SnapshotHandlerRestoreJob and > VerifySnapshotPartitionsJob have many code duplications. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22412) Unify snapshot validation tasks
[ https://issues.apache.org/jira/browse/IGNITE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22412: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Unify snapshot validation tasks > --- > > Key: IGNITE-22412 > URL: https://issues.apache.org/jira/browse/IGNITE-22412 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > We should bring some AbtsractSnapshotValidationJob into the task. > VerifyIncrementalSnapshotJob, SnapshotHandlerRestoreJob and > VerifySnapshotPartitionsJob have many code duplications. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19972) Add metrics of snapshot check
[ https://issues.apache.org/jira/browse/IGNITE-19972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-19972: - Assignee: Vladimir Steshin > Add metrics of snapshot check > - > > Key: IGNITE-19972 > URL: https://issues.apache.org/jira/browse/IGNITE-19972 > Project: Ignite > Issue Type: Task >Reporter: Julia Bakulina >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > Server nodes do not have metrics of snapshot check process state, but it is > necessary for the online analysis when snapshot check procedure started and > finished. Currently, snapshot check invoked at least by restore and check > commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[ https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22400: -- Fix Version/s: 2.17 > Fix unstable IgniteClusterSnapshotStreamerTest > --- > > Key: IGNITE-22400 > URL: https://issues.apache.org/jira/browse/IGNITE-22400 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.17 > > > Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not > flush streamer's data before the tests and do not wait untils streamer stops. > This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22401) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-22401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22401: -- Fix Version/s: 2.17 > Code cleanup > > > Key: IGNITE-22401 > URL: https://issues.apache.org/jira/browse/IGNITE-22401 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.17 > > > Fixes of the code style, abbeviations, unused code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22401) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-22401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22401: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Code cleanup > > > Key: IGNITE-22401 > URL: https://issues.apache.org/jira/browse/IGNITE-22401 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > Fixes of the code style, abbeviations, unused code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[ https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22400: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix unstable IgniteClusterSnapshotStreamerTest > --- > > Key: IGNITE-22400 > URL: https://issues.apache.org/jira/browse/IGNITE-22400 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not > flush streamer's data before the tests and do not wait untils streamer stops. > This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22401) Code cleanup
Vladimir Steshin created IGNITE-22401: - Summary: Code cleanup Key: IGNITE-22401 URL: https://issues.apache.org/jira/browse/IGNITE-22401 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin Fixes of the code style, abbeviations, unused code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[ https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22400: -- Labels: ise (was: ) > Fix unstable IgniteClusterSnapshotStreamerTest > --- > > Key: IGNITE-22400 > URL: https://issues.apache.org/jira/browse/IGNITE-22400 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not > flush streamer's data before the tests and do not wait untils streamer stops. > This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
Vladimir Steshin created IGNITE-22400: - Summary: Fix unstable IgniteClusterSnapshotStreamerTest Key: IGNITE-22400 URL: https://issues.apache.org/jira/browse/IGNITE-22400 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not flush streamer's data before the tests and do not wait untils streamer stops. This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22383) Status and progress of snapshot checking
[ https://issues.apache.org/jira/browse/IGNITE-22383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22383: -- Labels: (was: ise) > Status and progress of snapshot checking > - > > Key: IGNITE-22383 > URL: https://issues.apache.org/jira/browse/IGNITE-22383 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > > Currently, not every long snapshot oparation expose its progress to the > metrics and the status commands. Snapshot ckeck can take time but there is no > any metric for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22383) Status and progress of snapshot checking
[ https://issues.apache.org/jira/browse/IGNITE-22383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-22383. --- Resolution: Duplicate Duplicate of IGNITE-19972 > Status and progress of snapshot checking > - > > Key: IGNITE-22383 > URL: https://issues.apache.org/jira/browse/IGNITE-22383 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > Currently, not every long snapshot oparation expose its progress to the > metrics and the status commands. Snapshot ckeck can take time but there is no > any metric for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22383) Status and progress of snapshot checking
[ https://issues.apache.org/jira/browse/IGNITE-22383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22383: -- Description: Currently, not every long snapshot oparation expose its progress to the metrics and the status commands. Snapshot ckeck can take time but there is no any metric for it. (was: Currently, not every long snapshot oparation expose its status and progress to the metrics. Snapshot ckeck can take time but there is no any metric for it.) > Status and progress of snapshot checking > - > > Key: IGNITE-22383 > URL: https://issues.apache.org/jira/browse/IGNITE-22383 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > Currently, not every long snapshot oparation expose its progress to the > metrics and the status commands. Snapshot ckeck can take time but there is no > any metric for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22383) Status and progress of snapshot checking
[ https://issues.apache.org/jira/browse/IGNITE-22383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22383: -- Labels: ise (was: ) > Status and progress of snapshot checking > - > > Key: IGNITE-22383 > URL: https://issues.apache.org/jira/browse/IGNITE-22383 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > Currently, not every long snapshot oparation expose its status and progress > to the metrics. Snapshot ckeck can take time but there is no any metric for > it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22383) Status and progress of snapshot checking
Vladimir Steshin created IGNITE-22383: - Summary: Status and progress of snapshot checking Key: IGNITE-22383 URL: https://issues.apache.org/jira/browse/IGNITE-22383 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Currently, not every long snapshot oparation expose its status and progress to the metrics. Snapshot ckeck can take time but there is no any metric for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Description:
In the the snapshot validation, we do some metadata checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new SnapshotPartitionsVerifyTaskResult(metas, new
IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted caches while encryption is
disabled. To " +
"restore this snapshot, start Ignite with configured encryption and
the same " +
"master key.");
return;
}
{code}
Such checks should be moved to the task.
was:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Such checks should be moved to the task.
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the the snapshot validation, we do some metadata checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new SnapshotPartitionsVerifyTaskResult(metas, new
> IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(), new
> IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted caches while encryption is
> disabled. To " +
> "restore this snapshot, start Ignite with configured encryption
> and the same " +
> "master key.");
> return;
> }
> {code}
> Such checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Description:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Such checks should be moved to the task.
was:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Suck checks should be moved to the task.
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the the snapshot validation, we do some metaadas checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new
> SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(),
> new IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted
> caches while encryption is disabled. To " +
> "restore this snapshot, start Ignite with
> configured encryption and the same " +
> "master key.");
> return;
> }
> {code}
> Such checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-22182:
-
Assignee: Vladimir Steshin
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the the snapshot validation, we do some metaadas checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new
> SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(),
> new IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted
> caches while encryption is disabled. To " +
> "restore this snapshot, start Ignite with
> configured encryption and the same " +
> "master key.");
> return;
> }
> {code}
> Suck checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Fix Version/s: 2.17
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the the snapshot validation, we do some metaadas checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new
> SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(),
> new IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted
> caches while encryption is disabled. To " +
> "restore this snapshot, start Ignite with
> configured encryption and the same " +
> "master key.");
> return;
> }
> {code}
> Suck checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Description:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Suck checks should be moved to the task.
was:
In the the snapshot validation, we do some meatadas checks within
`IgniteSnapshotManager` instead dedicated `SnapshotMetadataVerificationTask`.
Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Suck checks should be moved to the task.
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> In the the snapshot validation, we do some metaadas checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new
> SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(),
> new IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted
> caches while encryption is disabled. To " +
> "restore this snapshot, start Ignite with
> configured encryption and the same " +
> "master key.");
> return;
> }
> {code}
> Suck checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Labels: ise (was: )
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: ise
>
> In the the snapshot validation, we do some metaadas checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new
> SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(),
> new IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted
> caches while encryption is disabled. To " +
> "restore this snapshot, start Ignite with
> configured encryption and the same " +
> "master key.");
> return;
> }
> {code}
> Suck checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
