[jira] [Commented] (IGNITE-21156) [IEP-114] Custom metrics introduction
[
https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838800#comment-17838800
]
Ignite TC Bot commented on IGNITE-21156:
{panel:title=Branch: [pull/11293/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11293/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 13{color} [[tests
6|https://ci2.ignite.apache.org/viewLog.html?buildId=7830855]]
* {color:#013220}IgniteCacheTestSuite13: CustomMetricsTest.testNullSupplier -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CustomMetricsTest.testIncompatibleMetricTypes - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13: CustomMetricsTest.testMetricName -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13: CustomMetricsTest.testWithService -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CustomMetricsTest.testCustomMetricNameNotCollidingWithSystemNames -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13: CustomMetricsTest.testIntMetric -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7830953buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-114] Custom metrics introduction
> -
>
> Key: IGNITE-21156
> URL: https://issues.apache.org/jira/browse/IGNITE-21156
> Project: Ignite
> Issue Type: Task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-114, ise
> Fix For: 2.17
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22072) Fix the extensions for Custom Metrics
[ https://issues.apache.org/jira/browse/IGNITE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22072: -- Labels: ise (was: ) > Fix the extensions for Custom Metrics > - > > Key: IGNITE-22072 > URL: https://issues.apache.org/jira/browse/IGNITE-22072 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Critical > Labels: ise > > The custom metrics expose new public _MetricRegistry_, renames internal > _MetricRegistry_->_MetricRegistryImpl_ and changes imports/API of > _CdcConsumer_. The related code won't compile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22072) Fix the extensions for Custom Metrics
[ https://issues.apache.org/jira/browse/IGNITE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22072: -- Summary: Fix the extensions for Custom Metrics (was: Fix the extensions for CustomMetrics) > Fix the extensions for Custom Metrics > - > > Key: IGNITE-22072 > URL: https://issues.apache.org/jira/browse/IGNITE-22072 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Critical > > The custom metrics expose new public _MetricRegistry_, renames internal > _MetricRegistry_->_MetricRegistryImpl_ and changes imports/API of > _CdcConsumer_. The related code won't compile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22072) Fix the extensions for CustomMetrics
Vladimir Steshin created IGNITE-22072: - Summary: Fix the extensions for CustomMetrics Key: IGNITE-22072 URL: https://issues.apache.org/jira/browse/IGNITE-22072 Project: Ignite Issue Type: Task Reporter: Vladimir Steshin The custom metrics expose new public _MetricRegistry_, renames internal _MetricRegistry_->_MetricRegistryImpl_ and changes imports/API of _CdcConsumer_. The related code won't compile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18937) Sql. Join of big number of table function takes unreasonable amount of time
[
https://issues.apache.org/jira/browse/IGNITE-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reassigned IGNITE-18937:
---
Assignee: Iurii Gerzhedovich
> Sql. Join of big number of table function takes unreasonable amount of time
> ---
>
> Key: IGNITE-18937
> URL: https://issues.apache.org/jira/browse/IGNITE-18937
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> The test
> {{org.apache.ignite.internal.sql.engine.planner.JoinCommutePlannerTest#commuteIsDisabledForBigJoinsOfTableFunctions}}
> takes too much time to finish (don't know actual timing, just killed the
> test after a minute), whereas the similar one but with tables (instead of
> table function) takes only a few seconds. Let's investigate this problem and
> fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21953) Cover SQL E021-01(Character string types. CHARACTER data type) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-21953: --- Assignee: Iurii Gerzhedovich > Cover SQL E021-01(Character string types. CHARACTER data type) feature by > tests > --- > > Key: IGNITE-21953 > URL: https://issues.apache.org/jira/browse/IGNITE-21953 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for E021-01(Character string types. CHARACTER > data type) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21888) Remove MvccVersion and MvccUpdateVersionAware
[ https://issues.apache.org/jira/browse/IGNITE-21888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21888: Description: Delete MvccVersion, MvccVersionImpl and MvccUpdateVersionAware (was: Delete MvccVersion and MvccUpdateVersionAware) > Remove MvccVersion and MvccUpdateVersionAware > - > > Key: IGNITE-21888 > URL: https://issues.apache.org/jira/browse/IGNITE-21888 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > > Delete MvccVersion, MvccVersionImpl and MvccUpdateVersionAware -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18492:
--
Description:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the word VARCHAR)^{color}
was:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
> SQL: Inconsistent behavior of LENGTH limit for CHAR data type
> -
>
> Key: IGNITE-18492
> URL: https://issues.apache.org/jira/browse/IGNITE-18492
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When I create a table with {{CHAR(length)}} column, it's still possible to
> insert character values with length greater than given limit.
> {code:sql}
> sql-cli> create table xx (pk int primary key, f1 char(5));
> Updated 0 rows.
> sql-cli> insert into xx values (1, 'abcdefgh');
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> In other hand, length limit is applied when I insert non-char value that's
> casted into {{CHAR}} implicitly. With the same table as above:
> {code:sql}
> sql-cli> insert into xx values (2, 1234567);
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 2 │ 12345║
> ╟┼──╢
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> Behavior should be consistent: ether strip both values down to the given
> length limit, or deny to insert too long values in both cases (like it's done
> in other DBs, like postgresql).
>
> Dynamic params can be processed to, check
> IgniteSqlValidator#inferDynamicParamType
> NOTE
> VARCHAR is also affected
> {color:#505f79}^(the note was added so that the ticket would be included in
> the search for the word VARCHAR)^{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18492:
--
Description:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(this note was added so that the ticket would be included in
the search for the keyword VARCHAR)^{color}
was:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the keyword VARCHAR)^{color}
> SQL: Inconsistent behavior of LENGTH limit for CHAR data type
> -
>
> Key: IGNITE-18492
> URL: https://issues.apache.org/jira/browse/IGNITE-18492
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When I create a table with {{CHAR(length)}} column, it's still possible to
> insert character values with length greater than given limit.
> {code:sql}
> sql-cli> create table xx (pk int primary key, f1 char(5));
> Updated 0 rows.
> sql-cli> insert into xx values (1, 'abcdefgh');
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> In other hand, length limit is applied when I insert non-char value that's
> casted into {{CHAR}} implicitly. With the same table as above:
> {code:sql}
> sql-cli> insert into xx values (2, 1234567);
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 2 │ 12345║
> ╟┼──╢
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> Behavior should be consistent: ether strip both values down to the given
> length limit, or deny to insert too long values in both cases (like it's done
> in other DBs, like postgresql).
>
> Dynamic params can be processed to, check
> IgniteSqlValidator#inferDynamicParamType
> NOTE
> VARCHAR is also affected
> {color:#505f79}^(this note was added so that the ticket would be included in
> the search for the keyword VARCHAR)^{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18492:
--
Description:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the keyword VARCHAR)^{color}
was:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the word VARCHAR)^{color}
> SQL: Inconsistent behavior of LENGTH limit for CHAR data type
> -
>
> Key: IGNITE-18492
> URL: https://issues.apache.org/jira/browse/IGNITE-18492
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When I create a table with {{CHAR(length)}} column, it's still possible to
> insert character values with length greater than given limit.
> {code:sql}
> sql-cli> create table xx (pk int primary key, f1 char(5));
> Updated 0 rows.
> sql-cli> insert into xx values (1, 'abcdefgh');
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> In other hand, length limit is applied when I insert non-char value that's
> casted into {{CHAR}} implicitly. With the same table as above:
> {code:sql}
> sql-cli> insert into xx values (2, 1234567);
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 2 │ 12345║
> ╟┼──╢
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> Behavior should be consistent: ether strip both values down to the given
> length limit, or deny to insert too long values in both cases (like it's done
> in other DBs, like postgresql).
>
> Dynamic params can be processed to, check
> IgniteSqlValidator#inferDynamicParamType
> NOTE
> VARCHAR is also affected
> {color:#505f79}^(the note was added so that the ticket would be included in
> the search for the keyword VARCHAR)^{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21935) Cover SQL E153(Updatable queries with subqueries) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838696#comment-17838696 ] Iurii Gerzhedovich commented on IGNITE-21935: - [~xtern] could you please review the patch? > Cover SQL E153(Updatable queries with subqueries) feature by tests > -- > > Key: IGNITE-21935 > URL: https://issues.apache.org/jira/browse/IGNITE-21935 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We don't have at all any tests for E153(Updatable queries with subqueries) > SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21923) Cover SQL E051-09(Basic query specification, Rename columns in the FROM clause) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838697#comment-17838697 ] Iurii Gerzhedovich commented on IGNITE-21923: - [~xtern] could you please review the patch? > Cover SQL E051-09(Basic query specification, Rename columns in the FROM > clause) feature by tests > > > Key: IGNITE-21923 > URL: https://issues.apache.org/jira/browse/IGNITE-21923 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We don't have at all any tests for E051-09(Basic query specification, Rename > columns in the FROM clause) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22069) Fix contention on expiration for persistent caches
[
https://issues.apache.org/jira/browse/IGNITE-22069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838695#comment-17838695
]
Aleksey Plekhanov commented on IGNITE-22069:
Benchmark results ({{{}JmhCacheExpireBenchmark{}}}) on my laptop:
Before fix:
{noformat}
Benchmark (persistence) Mode Cnt Score
Error Units
JmhCacheExpireBenchmark.putWithExpire TRUE thrpt 3 29,968 ±
15,287 ops/ms
{noformat}
After fix:
{noformat}
Benchmark (persistence) Mode Cnt Score
Error Units
JmhCacheExpireBenchmark.putWithExpire TRUE thrpt3 172,777 ±
22,737 ops/ms
{noformat}
> Fix contention on expiration for persistent caches
> --
>
> Key: IGNITE-22069
> URL: https://issues.apache.org/jira/browse/IGNITE-22069
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We've fixed contention on expiration for in-memory caches by IGNITE-14341 and
> IGNITE-21929 tickets, but persistent caches use another method to expire
> entries and this method should be fixed too. Moreover, there are some other
> optimizations related to expiration we can made:
> # Use batch pending tree entries removal for persistent caches (already
> implemented for in-memory)
> # Randomize iteration over cache data stores during expiration to reduce
> contention
> # For each transaction, we try to expire entries for every cache in the
> cluster. At least we can limit the list of caches to caches related to
> transaction.
> # On cache destroy batch removal from pending entries tree can be used
> (instead of one-by-one deletion).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21888) Remove MvccVersion and MvccUpdateVersionAware
[ https://issues.apache.org/jira/browse/IGNITE-21888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21888: Summary: Remove MvccVersion and MvccUpdateVersionAware (was: Remove MvccSnapshot) > Remove MvccVersion and MvccUpdateVersionAware > - > > Key: IGNITE-21888 > URL: https://issues.apache.org/jira/browse/IGNITE-21888 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > > Delete MvccSnapshot functionality -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21888) Remove MvccVersion and MvccUpdateVersionAware
[ https://issues.apache.org/jira/browse/IGNITE-21888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21888: Description: Delete MvccVersion and MvccUpdateVersionAware (was: Delete MvccSnapshot functionality) > Remove MvccVersion and MvccUpdateVersionAware > - > > Key: IGNITE-21888 > URL: https://issues.apache.org/jira/browse/IGNITE-21888 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > > Delete MvccVersion and MvccUpdateVersionAware -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22071) Async component stop
Kirill Sizov created IGNITE-22071:
--
Summary: Async component stop
Key: IGNITE-22071
URL: https://issues.apache.org/jira/browse/IGNITE-22071
Project: Ignite
Issue Type: Task
Reporter: Kirill Sizov
IGNITE-20477 made {{IgniteComponent.start}} asynchronous. Now it's time to make
a symmetrical change to {{IgniteComponent.stop}}. It should also become
asyncronous.
Additionally, the methods should be renamed according to the Code Style
Guidelines to startAsync and stopAsync accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22071) Async component stop
[
https://issues.apache.org/jira/browse/IGNITE-22071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-22071:
--
Assignee: Kirill Sizov
> Async component stop
>
>
> Key: IGNITE-22071
> URL: https://issues.apache.org/jira/browse/IGNITE-22071
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> IGNITE-20477 made {{IgniteComponent.start}} asynchronous. Now it's time to
> make a symmetrical change to {{IgniteComponent.stop}}. It should also become
> asyncronous.
> Additionally, the methods should be renamed according to the Code Style
> Guidelines to startAsync and stopAsync accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15616) Calcite. Failed to parse UPDATE query.
[
https://issues.apache.org/jira/browse/IGNITE-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-15616:
--
Description:
Seems we need to support DEFAULT in Parser.jj or extend it
{noformat}
SqlNode SqlUpdate() :
...
id = SimpleIdentifier() {
targetColumnList.add(id);
}
// TODO: support DEFAULT also
{noformat}
{noformat}
statement ok
UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
i1.id id = SimpleIdentifier() {
targetColumnList.add(id);
}
// TODO: support DEFAULT also
{noformat}
{noformat}
statement ok
UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
i1.id Calcite. Failed to parse UPDATE query.
> --
>
> Key: IGNITE-15616
> URL: https://issues.apache.org/jira/browse/IGNITE-15616
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, ignite-3
>
> Seems we need to support DEFAULT in Parser.jj or extend it
> {noformat}
> SqlNode SqlUpdate() :
> ...
> id = SimpleIdentifier() {
> targetColumnList.add(id);
> }
> // TODO: support DEFAULT also
> {noformat}
>
> {noformat}
> statement ok
> UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
> i1.id query II
> SELECT id, i FROM integers ORDER BY id
>
> 1 NULL
> 2 NULL
> 3 2
> 4 3
> {noformat}
> {noformat}
> Statement [queries=ArrayList [UPDATE integers i1 SET i=DEFAULT WHERE
> i=(SELECT MIN(i) FROM integers WHERE i1.id at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:205)
> {noformat}
> {noformat}
> /subquery/scalar/test_update_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15616) Calcite. Failed to parse UPDATE query.
[
https://issues.apache.org/jira/browse/IGNITE-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838687#comment-17838687
]
Iurii Gerzhedovich commented on IGNITE-15616:
-
The issue is still actual and it doesn't matter implemented it in Calcite or not
> Calcite. Failed to parse UPDATE query.
> --
>
> Key: IGNITE-15616
> URL: https://issues.apache.org/jira/browse/IGNITE-15616
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, ignite-3
>
> Seems we nned to support DEFAULT in Parser.jj or extend it
> {noformat}
> SqlNode SqlUpdate() :
> ...
> id = SimpleIdentifier() {
> targetColumnList.add(id);
> }
> // TODO: support DEFAULT also
> {noformat}
>
> {noformat}
> statement ok
> UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
> i1.id query II
> SELECT id, i FROM integers ORDER BY id
>
> 1 NULL
> 2 NULL
> 3 2
> 4 3
> {noformat}
> {noformat}
> Statement [queries=ArrayList [UPDATE integers i1 SET i=DEFAULT WHERE
> i=(SELECT MIN(i) FROM integers WHERE i1.id at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:205)
> {noformat}
> {noformat}
> /subquery/scalar/test_update_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (IGNITE-15616) Calcite. Failed to parse UPDATE query.
[
https://issues.apache.org/jira/browse/IGNITE-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reopened IGNITE-15616:
-
> Calcite. Failed to parse UPDATE query.
> --
>
> Key: IGNITE-15616
> URL: https://issues.apache.org/jira/browse/IGNITE-15616
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, ignite-3
>
> Seems we nned to support DEFAULT in Parser.jj or extend it
> {noformat}
> SqlNode SqlUpdate() :
> ...
> id = SimpleIdentifier() {
> targetColumnList.add(id);
> }
> // TODO: support DEFAULT also
> {noformat}
>
> {noformat}
> statement ok
> UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
> i1.id query II
> SELECT id, i FROM integers ORDER BY id
>
> 1 NULL
> 2 NULL
> 3 2
> 4 3
> {noformat}
> {noformat}
> Statement [queries=ArrayList [UPDATE integers i1 SET i=DEFAULT WHERE
> i=(SELECT MIN(i) FROM integers WHERE i1.id at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:205)
> {noformat}
> {noformat}
> /subquery/scalar/test_update_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22070) Sql. incorrect working
[
https://issues.apache.org/jira/browse/IGNITE-22070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich resolved IGNITE-22070.
-
Resolution: Invalid
> Sql. incorrect working
> ---
>
> Key: IGNITE-22070
> URL: https://issues.apache.org/jira/browse/IGNITE-22070
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Priority: Major
>
> When we use the E051-09 SQL standard feature in such manner :
> {code:java}
> SELECT ALL alias . X , Y FROM tab AS alias (X, Y) order by x{code}
> We obtain the following error message:
> {code:java}
> List of column aliases must have same degree as table; table has 3 columns
> ('__p_key', 'A', 'B'), whereas alias list has 2 columns{code}
> We shouldn't show to user our guts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21996:
--
Ignite Flags: (was: Docs Required)
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22070) Sql. incorrect working
[
https://issues.apache.org/jira/browse/IGNITE-22070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22070:
Description:
When we use the E051-09 SQL standard feature in such manner :
{code:java}
SELECT ALL alias . X , Y FROM tab AS alias (X, Y) order by x{code}
We obtain the following error message:
{code:java}
List of column aliases must have same degree as table; table has 3 columns
('__p_key', 'A', 'B'), whereas alias list has 2 columns{code}
We shouldn't show to user our guts
was:
When we use the E051-09 SQL standard feature in such manner :
{code:java}
SELECT ALL alias . X , Y FROM tab AS alias (X, Y) order by x{code}
We Obtain e
{code:java}
List of column aliases must have same degree as table; table has 3 columns
('__p_key', 'A', 'B'), whereas alias list has 2 columns{code}
> Sql. incorrect working
> ---
>
> Key: IGNITE-22070
> URL: https://issues.apache.org/jira/browse/IGNITE-22070
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Priority: Major
>
> When we use the E051-09 SQL standard feature in such manner :
> {code:java}
> SELECT ALL alias . X , Y FROM tab AS alias (X, Y) order by x{code}
> We obtain the following error message:
> {code:java}
> List of column aliases must have same degree as table; table has 3 columns
> ('__p_key', 'A', 'B'), whereas alias list has 2 columns{code}
> We shouldn't show to user our guts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22070) Sql. incorrect working
Iurii Gerzhedovich created IGNITE-22070:
---
Summary: Sql. incorrect working
Key: IGNITE-22070
URL: https://issues.apache.org/jira/browse/IGNITE-22070
Project: Ignite
Issue Type: Improvement
Reporter: Iurii Gerzhedovich
When we use the E051-09 SQL standard feature in such manner :
{code:java}
SELECT ALL alias . X , Y FROM tab AS alias (X, Y) order by x{code}
We Obtain e
{code:java}
List of column aliases must have same degree as table; table has 3 columns
('__p_key', 'A', 'B'), whereas alias list has 2 columns{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18647) SQL API: Implement missed Statement and StatementBuilder methods.
[ https://issues.apache.org/jira/browse/IGNITE-18647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-18647: -- Fix Version/s: 3.0.0-beta2 > SQL API: Implement missed Statement and StatementBuilder methods. > - > > Key: IGNITE-18647 > URL: https://issues.apache.org/jira/browse/IGNITE-18647 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21435) Sql. Catalog DefaultValue should not depend on Serializable.
[
https://issues.apache.org/jira/browse/IGNITE-21435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838659#comment-17838659
]
Maksim Zhuravkov commented on IGNITE-21435:
---
[~xtern] could you please review my patch?
> Sql. Catalog DefaultValue should not depend on Serializable.
>
>
> Key: IGNITE-21435
> URL: https://issues.apache.org/jira/browse/IGNITE-21435
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently {{ConstantValue}} (inside
> {{org.apache.ignite.internal.catalog.commands.DefaultValue}}) may hold any
> {{Serializable}} object.
> This should be revised to allow custom serialization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22026) Fix incorrect retry logic in GridCacheIoManager send method
[
https://issues.apache.org/jira/browse/IGNITE-22026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838655#comment-17838655
]
Ignite TC Bot commented on IGNITE-22026:
{panel:title=Branch: [pull/11311/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11311/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 13{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=7829236]]
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=0] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=1] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=0] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=3] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=10] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=1] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=3] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=10] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7829334buildTypeId=IgniteTests24Java8_RunAll]
> Fix incorrect retry logic in GridCacheIoManager send method
> ---
>
> Key: IGNITE-22026
> URL: https://issues.apache.org/jira/browse/IGNITE-22026
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: GridCacheIoManagerRetryTest.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{GridCacheIoManager#send}}[1] and
> {{GridCacheIoManager#sendOrderedMessage}}[2] have incorrect {{retryCnt}}
> comparison in catch block and real retries count will be one less, than
> configured.
> Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
> {{IgniteCheckedException}} has been thrown during sending of message because
> of network timeout, error, etc., then no actual retries will happen and
> message will be lost.
> Reproducer: [^GridCacheIoManagerRetryTest.patch]
> Links:
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22001) Throw specific exception if during writeTableAssignmentsToMetastore process was interrupted
[
https://issues.apache.org/jira/browse/IGNITE-22001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-22001:
-
Fix Version/s: 3.0.0-beta2
> Throw specific exception if during writeTableAssignmentsToMetastore process
> was interrupted
> ---
>
> Key: IGNITE-22001
> URL: https://issues.apache.org/jira/browse/IGNITE-22001
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> h2. The problem
> In {{TableManager#writeTableAssignmentsToMetastore:752}} as a result of
> output {{CompletableFuture}} returns {{{}null{}}}-value. In cases of
> {{writeTableAssignmentsToMetastore}} method's using it leads to sudden
> {{NullPointerException}} without clear understandings of the reasons of such
> situation.
> h2. The solution
> Instead of returning {{{}null{}}}-value re-throw more specific exception with
> given assignments list to write in metastorage, and table identifier that
> should help to investigate cases of the method interruption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22065) Table partition API
[ https://issues.apache.org/jira/browse/IGNITE-22065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-22065: -- Assignee: Mikhail Pochatkin > Table partition API > --- > > Key: IGNITE-22065 > URL: https://issues.apache.org/jira/browse/IGNITE-22065 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > IEP [IEP-120: MapReduce API - Apache Ignite - Apache Software > Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-120%3A+MapReduce+API] > > Need to implement part about Table API. > # Modify Table interface > # HashPartition > # PartitionManager -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21996:
--
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21996:
-
Assignee: Pavel Pereslegin
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22069) Fix contention on expiration for persistent caches
Aleksey Plekhanov created IGNITE-22069: -- Summary: Fix contention on expiration for persistent caches Key: IGNITE-22069 URL: https://issues.apache.org/jira/browse/IGNITE-22069 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov We've fixed contention on expiration for in-memory caches by IGNITE-14341 and IGNITE-21929 tickets, but persistent caches use another method to expire entries and this method should be fixed too. Moreover, there are some other optimizations related to expiration we can made: # Use batch pending tree entries removal for persistent caches (already implemented for in-memory) # Randomize iteration over cache data stores during expiration to reduce contention # For each transaction, we try to expire entries for every cache in the cluster. At least we can limit the list of caches to caches related to transaction. # On cache destroy batch removal from pending entries tree can be used (instead of one-by-one deletion). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22068) Inconsistent API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-22068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-22068: -- Description: When running a query through thin client Criteria API and SQL API the results are sometimes differs with the same client. Reproducer is attached. For some reason, the test only fails at the second repetition. Leaving only the countCriteria line and comparing it with the recordCount doesn't fail the test. was: When running a query through thin client Criteria API and SQL API the results are sometimes differs with the same client. Reproducer is attached. For some reason, the test only fails at the second repetition. > Inconsistent API behaviour > -- > > Key: IGNITE-22068 > URL: https://issues.apache.org/jira/browse/IGNITE-22068 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Attachments: CountTest-1.java > > > When running a query through thin client Criteria API and SQL API the results > are sometimes differs with the same client. > Reproducer is attached. > For some reason, the test only fails at the second repetition. > Leaving only the countCriteria line and comparing it with the recordCount > doesn't fail the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22068) Inconsistent API behaviour
Vadim Pakhnushev created IGNITE-22068: - Summary: Inconsistent API behaviour Key: IGNITE-22068 URL: https://issues.apache.org/jira/browse/IGNITE-22068 Project: Ignite Issue Type: Bug Components: sql, thin client Reporter: Vadim Pakhnushev Attachments: CountTest-1.java When running a query through thin client Criteria API and SQL API the results are sometimes differs with the same client. Reproducer is attached. For some reason, the test only fails at the second repetition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21937) Cover SQL F041-05(Basic joined table. Outer joins can be nested) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21937: --- Assignee: Evgeny Stanilovsky > Cover SQL F041-05(Basic joined table. Outer joins can be nested) feature by > tests > - > > Key: IGNITE-21937 > URL: https://issues.apache.org/jira/browse/IGNITE-21937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F041-05(Basic joined table. Outer joins > can be nested) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22067) Make lease distribution more even
Denis Chudov created IGNITE-22067: - Summary: Make lease distribution more even Key: IGNITE-22067 URL: https://issues.apache.org/jira/browse/IGNITE-22067 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Currently, if we have a cluster of 3 nodes and a zone of 5 partitions, there is relatively high chance that some node will have no primary replica for any partition located on it. For 10 partition this chance is much lower but still exists. It shows that LeaseUpdater#nextLeaseHolder provides distribution far from even. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21836) KeyValueView. GetNullable produces confusing error for a PoJo when field / column nullability do not match
[
https://issues.apache.org/jira/browse/IGNITE-21836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-21836:
Priority: Major (was: Minor)
> KeyValueView. GetNullable produces confusing error for a PoJo when field /
> column nullability do not match
> --
>
> Key: IGNITE-21836
> URL: https://issues.apache.org/jira/browse/IGNITE-21836
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> GetNullable method of KeyValueView produces a confusing error for a PoJo when
> a field is primitive but underlying column is nullable:
> {code:java}
> public class ItKvTest extends BaseSqlIntegrationTest {
> public static class BoolStr {
> boolean boolCol;
> String strCol;
> }
> @Test
> public void testGetNullable() {
> sql("CREATE TABLE t0 (ID INTEGER PRIMARY KEY, boolCol BOOLEAN, strCol
> VARCHAR)");
> Table table = CLUSTER.aliveNode().tables().table("T0");
> KeyValueView view =
> table.keyValueView(Mapper.of(Integer.class), Mapper.of(BoolStr.class));
> view.put(null, 1, null);
> view.getNullable(null, 1);
> }
> }
> {code}
> {code:java}
> org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
> TraceId:ef2d9c71-8f2d-4279-99fc-25e8e14ede40 Failed to write field [id=0]
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:524)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$16(KeyValueViewImpl.java:225)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:180)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2341)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:180)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:171)
> at
> org.apache.ignite.internal.table.AbstractTableView.doOperation(AbstractTableView.java:147)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.putAsync(KeyValueViewImpl.java:224)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$put$15(KeyValueViewImpl.java:216)
> at
> org.apache.ignite.internal.table.AbstractTableView.sync(AbstractTableView.java:124)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.put(KeyValueViewImpl.java:216)
> at
> org.apache.ignite.internal.sql.api.ItKevtest.testGetNullable(ItKevtest.java:24)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:ef2d9c71-8f2d-4279-99fc-25e8e14ede40 Failed to write
> field [id=0]
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeObject(Marshaller.java:274)
> at
> org.apache.ignite.internal.schema.marshaller.reflection.KvMarshallerImpl.marshal(KvMarshallerImpl.java:102)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:522)
> ... 15 more
> Caused by: java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at
> java.base/java.lang.invoke.VarHandleBooleans$FieldInstanceReadOnly.get(VarHandleBooleans.java:90)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$VarHandleAccessor.get(FieldAccessor.java:552)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$BooleanPrimitiveAccessor.write0(FieldAccessor.java:581)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 18 more
> {code}
> This error message can be improved to say exactly what is wrong with user
> configuration and how to fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22062) RO transaction does not close cursor when exception is thrown
[ https://issues.apache.org/jira/browse/IGNITE-22062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-22062: -- Assignee: Vladislav Pyatkov > RO transaction does not close cursor when exception is thrown > - > > Key: IGNITE-22062 > URL: https://issues.apache.org/jira/browse/IGNITE-22062 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > If an RO transaction starts and executes some scan operation, and, for some > reason, the scan cursor does not close until the transaction is in a final > state. The behavior is different for RW transactions because RW transactions > go to the final state in case of any exception. > Although an RO transaction does not have to be closed in the case of an > exception in an operation, a scan cursor that is opened during the operation, > is useless and can be closed. > h3. Definition of done > If an RO transaction gets an exception during a scan operation, the scan > cursor has to be closed after the exception is caught by the end user code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21835) Cleanup MvccUtils and enum RowData
[ https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21835: Description: To cleanup MvccUtils and enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS. Delete MVCC classes: * MvccVersion * MvccVersionImpl * MvccUpdateVersionAware. The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345 was: To delete unused Mvcc code from enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS and cleanup MvccUtils. The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345 > Cleanup MvccUtils and enum RowData > --- > > Key: IGNITE-21835 > URL: https://issues.apache.org/jira/browse/IGNITE-21835 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > Time Spent: 0.5h > Remaining Estimate: 0h > > To cleanup MvccUtils and enum RowData: > * LINK_ONLY > * LINK_WITH_HEADER > * NO_KEY_WTH_HINTS. > Delete MVCC classes: > * MvccVersion > * MvccVersionImpl > * MvccUpdateVersionAware. > The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21835) Cleanup MvccUtils and enum RowData
[
https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838486#comment-17838486
]
Ignite TC Bot commented on IGNITE-21835:
{panel:title=Branch: [pull/11318/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11318/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7829444buildTypeId=IgniteTests24Java8_RunAll]
> Cleanup MvccUtils and enum RowData
> ---
>
> Key: IGNITE-21835
> URL: https://issues.apache.org/jira/browse/IGNITE-21835
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Major
> Labels: ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To delete unused Mvcc code from enum RowData:
> * LINK_ONLY
> * LINK_WITH_HEADER
> * NO_KEY_WTH_HINTS
> and cleanup MvccUtils.
> The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21938) Cover SQL F041-07(Basic joined table. The inner table in a left or right outer join can also be used in an inner join) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21938: --- Assignee: Evgeny Stanilovsky > Cover SQL F041-07(Basic joined table. The inner table in a left or right > outer join can also be used in an inner join) feature by tests > --- > > Key: IGNITE-21938 > URL: https://issues.apache.org/jira/browse/IGNITE-21938 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F041-07(Basic joined table. The inner > table in a left or right outer join can also be used in an inner join) SQL > feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
