[jira] [Updated] (IGNITE-14609) Document old and new async continuation behavior
[
https://issues.apache.org/jira/browse/IGNITE-14609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14609:
Description:
IGNITE-12033 changed the default async behavior for cache operations in Java
and .NET, plus Compute operations in .NET.
Document old and new async continuation behavior for Java and .NET.
Java:
* Update
https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
* Mention changes in upcoming 2.11
* Fix IgniteFuture javadoc (listen methods)
.NET:
* Add dedicated async page to {{.NET Specific}} section
* Explain cache async ops
* Explain known issues in Compute (Reduce method gets blocked)
* Add a note to Troubleshooting with a link to async page
* Mention changes in upcoming 2.11
was:
IGNITE-12033 changed the default async behavior for cache operations in Java
and .NET, plus Compute operations in .NET.
Document old and new async continuation behavior for Java and .NET.
Java:
* Update
https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
* Mention changes in upcoming 2.11
.NET:
* Add dedicated async page to {{.NET Specific}} section
* Explain cache async ops
* Explain known issues in Compute (Reduce method gets blocked)
* Add a note to Troubleshooting with a link to async page
* Mention changes in upcoming 2.11
> Document old and new async continuation behavior
>
>
> Key: IGNITE-14609
> URL: https://issues.apache.org/jira/browse/IGNITE-14609
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.11
>
>
> IGNITE-12033 changed the default async behavior for cache operations in Java
> and .NET, plus Compute operations in .NET.
> Document old and new async continuation behavior for Java and .NET.
> Java:
> * Update
> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
> * Mention changes in upcoming 2.11
> * Fix IgniteFuture javadoc (listen methods)
> .NET:
> * Add dedicated async page to {{.NET Specific}} section
> * Explain cache async ops
> * Explain known issues in Compute (Reduce method gets blocked)
> * Add a note to Troubleshooting with a link to async page
> * Mention changes in upcoming 2.11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14621) Ignite Extensions: change spring-data-*-ext modules names to align with a directory name
Amelchev Nikita created IGNITE-14621:
Summary: Ignite Extensions: change spring-data-*-ext modules names
to align with a directory name
Key: IGNITE-14621
URL: https://issues.apache.org/jira/browse/IGNITE-14621
Project: Ignite
Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
Change the following modules names:
{{ignite-spring-data_2.2-ext}}
{{ignite-spring-data_2.0-ext}}
on
{{ignite-spring-data-2.2-ext}}
{{ignite-spring-data-2.0-ext}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14620) GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326912#comment-17326912
]
Ignite TC Bot commented on IGNITE-14620:
{panel:title=Branch: [pull/9031/head] Base: [master] : Possible Blockers
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5976225]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5976168]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySegmentationAndConnectionRestoreTest.testConnectionRestore1 -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_KillCoordinator_5
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5976212]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testDropNoIndexPartitionedAtomicNear
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateIndexWithParallelismPartitionedTransactional
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests 1 TC_SERVICE_MESSAGE
|https://ci.ignite.apache.org/viewLog.html?buildId=5976207]]
* dll:
PlatformCacheTest.TestExpiryPolicyRemovesValuesFromPlatformCache(ServerLocal) -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS (Indexing){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5976200]]
* IgnitePdsWithIndexingTestSuite:
IgnitePdsIndexingDefragmentationTest.testFailoverIncompletedPartition1 - Test
has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsWithIndexingTestSuite:
IgniteClusterSnapshotCheckWithIndexesTest.testClusterSnapshotCheckWithNodeFilter
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/9031/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5976233&buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is flaky
> ---
>
> Key: IGNITE-14620
> URL: https://issues.apache.org/jira/browse/IGNITE-14620
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.11
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridCacheAsyncOperationsLimitSelfTest#testAsyncOps became flaky because of
> changes from IGNITE-12033
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14558) Add information about javadoc validation and generation commands to DEVNOTES.md
[
https://issues.apache.org/jira/browse/IGNITE-14558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14558:
--
Reviewer: Andrey Mashenkov (was: Andrey N. Gura)
> Add information about javadoc validation and generation commands to
> DEVNOTES.md
>
>
> Key: IGNITE-14558
> URL: https://issues.apache.org/jira/browse/IGNITE-14558
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://issues.apache.org/jira/browse/IGNITE-13751 is implemented and merged
> but DEVNOTES.md is not updated.
> Information about javadoc validation and generation commands should be added
> to DEVNOTES.md.
> Also, there is unresolved variable:
> {code:java}
> ${current.year} Copyright © Apache Software Foundation
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14620) GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is flaky
Pavel Tupitsyn created IGNITE-14620: --- Summary: GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is flaky Key: IGNITE-14620 URL: https://issues.apache.org/jira/browse/IGNITE-14620 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.11 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.11 GridCacheAsyncOperationsLimitSelfTest#testAsyncOps became flaky because of changes from IGNITE-12033 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14620) GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14620: Ignite Flags: (was: Docs Required,Release Notes Required) > GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is flaky > --- > > Key: IGNITE-14620 > URL: https://issues.apache.org/jira/browse/IGNITE-14620 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.11 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.11 > > > GridCacheAsyncOperationsLimitSelfTest#testAsyncOps became flaky because of > changes from IGNITE-12033 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14607) Regex Based Filter in IPFinders
[ https://issues.apache.org/jira/browse/IGNITE-14607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-14607: - Assignee: Atri Sharma > Regex Based Filter in IPFinders > --- > > Key: IGNITE-14607 > URL: https://issues.apache.org/jira/browse/IGNITE-14607 > Project: Ignite > Issue Type: Sub-task >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This Jira tracks the effort to implement regex based IP filtering in IPFinders -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14469) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
[ https://issues.apache.org/jira/browse/IGNITE-14469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326668#comment-17326668 ] Eduard Rakhmankulov commented on IGNITE-14469: -- [~ktkale...@gridgain.com] please make code review. > Adding a list of caches that will not be forced to rebuild indexes to the > control.sh --cache indexes_force_rebuild > -- > > Key: IGNITE-14469 > URL: https://issues.apache.org/jira/browse/IGNITE-14469 > Project: Ignite > Issue Type: Improvement > Components: control.sh, sql >Reporter: Kirill Tkalenko >Assignee: Eduard Rakhmankulov >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > After the IGNITE-14321 is implemented, it will be necessary to add to the > command *control.sh --cache indexes_force_rebuild* the ability to display to > the user that the forced rebuilding of the indexes is impossible, since they > are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14469) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
[
https://issues.apache.org/jira/browse/IGNITE-14469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326665#comment-17326665
]
Ignite TC Bot commented on IGNITE-14469:
{panel:title=Branch: [pull/9023/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9023/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5975689]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexForceRebuildTest.testSequentialForceRebuildIndexes -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5975697&buildTypeId=IgniteTests24Java8_RunAll]
> Adding a list of caches that will not be forced to rebuild indexes to the
> control.sh --cache indexes_force_rebuild
> --
>
> Key: IGNITE-14469
> URL: https://issues.apache.org/jira/browse/IGNITE-14469
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh, sql
>Reporter: Kirill Tkalenko
>Assignee: Eduard Rakhmankulov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the IGNITE-14321 is implemented, it will be necessary to add to the
> command *control.sh --cache indexes_force_rebuild* the ability to display to
> the user that the forced rebuilding of the indexes is impossible, since they
> are already being rebuilt.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14601) Specs should use service's params instead of copying.
[
https://issues.apache.org/jira/browse/IGNITE-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326634#comment-17326634
]
Anton Vinogradov commented on IGNITE-14601:
---
[~ivandasch], [~northdragon], thanks for the review.
Merged into ignite-ducktape.
> Specs should use service's params instead of copying.
> -
>
> Key: IGNITE-14601
> URL: https://issues.apache.org/jira/browse/IGNITE-14601
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently a lot of params copied to spec.
> Need just to use {{self.service.xxx}} instead
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14411) Define minimal set of cluster components and their lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14411: - Description: In general components structure looks like following: !Screenshot from 2021-04-15 17-07-22.png! For more details please see [IEP-73|https://cwiki.apache.org/confluence/display/IGNITE/IEP-73%3A+Node+startup] For terms clarification and modules splinting logic please see [DEVLIST discussion|[http://apache-ignite-developers.2346864.n4.nabble.com/Terms-clarification-and-modules-splitting-logic-td52026.html#a52058]] was:In general components structure looks like following: > Define minimal set of cluster components and their lifecycle > > > Key: IGNITE-14411 > URL: https://issues.apache.org/jira/browse/IGNITE-14411 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73 > Fix For: 3.0.0-alpha2 > > Attachments: Screenshot from 2021-04-15 17-07-22.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > In general components structure looks like following: !Screenshot from > 2021-04-15 17-07-22.png! > For more details please see > [IEP-73|https://cwiki.apache.org/confluence/display/IGNITE/IEP-73%3A+Node+startup] > For terms clarification and modules splinting logic please see [DEVLIST > discussion|[http://apache-ignite-developers.2346864.n4.nabble.com/Terms-clarification-and-modules-splitting-logic-td52026.html#a52058]] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14411) Define minimal set of cluster components and their lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14411: - Attachment: Screenshot from 2021-04-15 17-07-22.png > Define minimal set of cluster components and their lifecycle > > > Key: IGNITE-14411 > URL: https://issues.apache.org/jira/browse/IGNITE-14411 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73 > Fix For: 3.0.0-alpha2 > > Attachments: Screenshot from 2021-04-15 17-07-22.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > In general components structure looks like following: -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14411) Define minimal set of cluster components and their lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14411: - Description: In general components structure looks like following: > Define minimal set of cluster components and their lifecycle > > > Key: IGNITE-14411 > URL: https://issues.apache.org/jira/browse/IGNITE-14411 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73 > Fix For: 3.0.0-alpha2 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > In general components structure looks like following: -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14545) Calcite engine. Unicode literal not supported
[
https://issues.apache.org/jira/browse/IGNITE-14545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326584#comment-17326584
]
Aleksey Plekhanov edited comment on IGNITE-14545 at 4/21/21, 2:32 PM:
--
It's relatively easy to support 16-bit unicode characters (I've raised the pull
request). But there is limited support for 32-bit characters, since java uses
16-bit Char array for strings. Length, substring, and some other methods treat
each 32-bit character as two 16-bit characters. For example, the result of
{{"🦆".length()}} will be 2. String functions in calcite reuse java {{String}}
methods and have the same problem. The result of {{SELECT CHAR_LENGTH('🦆}}')
will be 2. And we cannot change this behavior without rewriting Calcite string
functions. I'm not sure we need it right now.
was (Author: alex_pl):
It's relatively easy to support 16-bit unicode characters (I've raised the pull
request). But there is limited support for 32-bit characters, since java uses
16-bit Char array for strings. Length, substring, and some other methods treat
each 32-bit character as two 16-bit characters. For example, the result of
{{"🦆".length()}} will be 2. String functions in calcite reuse java {{String}}
methods and have the same problem. The result of {{SELECT
CHAR_LENGTH('{{🦆}}')}} will be 2. And we cannot change this behavior without
rewriting Calcite string functions. I'm not sure we need it right now.
> Calcite engine. Unicode literal not supported
> -
>
> Key: IGNITE-14545
> URL: https://issues.apache.org/jira/browse/IGNITE-14545
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unicode literal not supported.
> e.g. {{SELECT }}
> Tests:
> {{aggregate/aggregates/test_aggr_string.test}}
> {{types/string/test_unicode.test_ignored}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14545) Calcite engine. Unicode literal not supported
[
https://issues.apache.org/jira/browse/IGNITE-14545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326584#comment-17326584
]
Aleksey Plekhanov commented on IGNITE-14545:
It's relatively easy to support 16-bit unicode characters (I've raised the pull
request). But there is limited support for 32-bit characters, since java uses
16-bit Char array for strings. Length, substring, and some other methods treat
each 32-bit character as two 16-bit characters. For example, the result of
{{"🦆".length()}} will be 2. String functions in calcite reuse java {{String}}
methods and have the same problem. The result of {{SELECT
CHAR_LENGTH('{{🦆}}')}} will be 2. And we cannot change this behavior without
rewriting Calcite string functions. I'm not sure we need it right now.
> Calcite engine. Unicode literal not supported
> -
>
> Key: IGNITE-14545
> URL: https://issues.apache.org/jira/browse/IGNITE-14545
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unicode literal not supported.
> e.g. {{SELECT }}
> Tests:
> {{aggregate/aggregates/test_aggr_string.test}}
> {{types/string/test_unicode.test_ignored}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14619) Refactoring of GridDeploymentCommunication
Denis Chudov created IGNITE-14619: - Summary: Refactoring of GridDeploymentCommunication Key: IGNITE-14619 URL: https://issues.apache.org/jira/browse/IGNITE-14619 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov org.apache.ignite.internal.managers.deployment.GridDeploymentCommunication#sendResourceRequest uses "while" loop with mutex instead of future, and creates listeners for discovery events and communication messages for each request. This complicates the code and may affect class loading performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13019) Unexpected JOIN result when querying a single-node cluster
[
https://issues.apache.org/jira/browse/IGNITE-13019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326560#comment-17326560
]
Stanislav Lukyanov commented on IGNITE-13019:
-
[~amashenkov], on your comment about the performance - how bad do you think
it'll be? I actually like that currently in the code all checks are separate as
it makes them much either to read. Merging them all into a single method or a
chain of visitors might get pretty complicated... Do you think running a set of
benchmarks before merging will suffice to show that this doesn't hurt the
performance too much?
> Unexpected JOIN result when querying a single-node cluster
> --
>
> Key: IGNITE-13019
> URL: https://issues.apache.org/jira/browse/IGNITE-13019
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Check reproducer near,
> seems something wrong with pkey logic , if we change it - results will be ok.
> {code:java}
> @Test
> public void test() throws Exception {
> inlineSize = 10;
> startGrid(0);
> String t1 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno)\n" +
> " );";
> execSql(t1);
> String t2 = "CREATE TABLE emp\n" +
> " (\n" +
> "empno LONG,\n" +
> "ename VARCHAR,\n" +
> "job VARCHAR,\n" +
> "mgr INTEGER,\n" +
> "hiredate DATE,\n" +
> "sal LONG,\n" +
> "comm LONG,\n" +
> "deptno LONG,\n" +
> "CONSTRAINT pk_emp PRIMARY KEY (empno)\n" +
> " );";
> execSql(t2);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7839, 'KING', 'PRESIDENT', null,
> to_date('17-11-1981','dd-mm-'), 5000, null, 10);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values( 7698, 'BLAKE', 'MANAGER', 7839,
> to_date('1-5-1981','dd-mm-'), 2850, null, 30);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7782, 'CLARK', 'MANAGER', 7839,
> to_date('9-6-1981','dd-mm-'), 2450, null, 10);");
> List> vals1 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals1.size(), 2);
> List> vals2 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> //assertEquals(vals2.size(), 2); <--* uncomment for fail*
> execSql("drop table dept");
> String t3 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno, dname)\n" +
> " );";
> execSql(t3);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> List> vals11 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals11.size(), 2);
> List> vals22 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> assertEquals(vals22.size(), 2);
> }
> /** */
> private List> execSql(String qry) {
> return grid(0).context().query()
> .querySqlFields(new SqlFieldsQuery(qry).setLazy(true), false)
> .getAll();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13019) Unexpected JOIN result when querying a single-node cluster
[
https://issues.apache.org/jira/browse/IGNITE-13019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326558#comment-17326558
]
Stanislav Lukyanov commented on IGNITE-13019:
-
Some comments in the PR.
Also, I would like to raise a couple of additional suggestions.
First, I think it would be very helpful if we print an INFO-level message when
a partitioned cache is created that contains the primary and affinity key
columns and explains that the JOINs with other partitioned caches must use
either the affinity key or the primary key.
Second, I think it would be good to have a mode when an incorrect JOIN
condition throws an error instead of printing a warning. Furthermore, I think
the next minor Ignite version can have the error as default. The error can be
suppressed by changing a metastore property.
> Unexpected JOIN result when querying a single-node cluster
> --
>
> Key: IGNITE-13019
> URL: https://issues.apache.org/jira/browse/IGNITE-13019
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Check reproducer near,
> seems something wrong with pkey logic , if we change it - results will be ok.
> {code:java}
> @Test
> public void test() throws Exception {
> inlineSize = 10;
> startGrid(0);
> String t1 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno)\n" +
> " );";
> execSql(t1);
> String t2 = "CREATE TABLE emp\n" +
> " (\n" +
> "empno LONG,\n" +
> "ename VARCHAR,\n" +
> "job VARCHAR,\n" +
> "mgr INTEGER,\n" +
> "hiredate DATE,\n" +
> "sal LONG,\n" +
> "comm LONG,\n" +
> "deptno LONG,\n" +
> "CONSTRAINT pk_emp PRIMARY KEY (empno)\n" +
> " );";
> execSql(t2);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7839, 'KING', 'PRESIDENT', null,
> to_date('17-11-1981','dd-mm-'), 5000, null, 10);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values( 7698, 'BLAKE', 'MANAGER', 7839,
> to_date('1-5-1981','dd-mm-'), 2850, null, 30);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7782, 'CLARK', 'MANAGER', 7839,
> to_date('9-6-1981','dd-mm-'), 2450, null, 10);");
> List> vals1 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals1.size(), 2);
> List> vals2 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> //assertEquals(vals2.size(), 2); <--* uncomment for fail*
> execSql("drop table dept");
> String t3 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno, dname)\n" +
> " );";
> execSql(t3);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> List> vals11 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals11.size(), 2);
> List> vals22 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> assertEquals(vals22.size(), 2);
> }
> /** */
> private List> execSql(String qry) {
> return grid(0).context().query()
>
[jira] [Assigned] (IGNITE-13840) Rething API of Init*, change* classes
[ https://issues.apache.org/jira/browse/IGNITE-13840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-13840: -- Assignee: Ivan Bessonov > Rething API of Init*, change* classes > -- > > Key: IGNITE-13840 > URL: https://issues.apache.org/jira/browse/IGNITE-13840 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Ivan Bessonov >Priority: Major > > Right now, API of Init*, change* classes look too heavy and contain a lot of > code boilerplate. It needs to think about how to simplify it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13840) Rething API of Init*, change* classes
[ https://issues.apache.org/jira/browse/IGNITE-13840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326535#comment-17326535 ] Ivan Bessonov commented on IGNITE-13840: Init classes will be removed. > Rething API of Init*, change* classes > -- > > Key: IGNITE-13840 > URL: https://issues.apache.org/jira/browse/IGNITE-13840 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Ivan Bessonov >Priority: Major > > Right now, API of Init*, change* classes look too heavy and contain a lot of > code boilerplate. It needs to think about how to simplify it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14601) Specs should use service's params instead of copying.
[
https://issues.apache.org/jira/browse/IGNITE-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326528#comment-17326528
]
Anton Vinogradov commented on IGNITE-14601:
---
This task happened during the Snapshot test simplification.
The goal was to just change loader params and load another data again, without
node freeing and another IgniteAware instance creation.
Before:
{noformat}
loader = IgniteApplicationService(
self.test_context,
client_config,
java_class_name="org.apache.ignite.internal.ducktest.tests.snapshot_test.DataLoaderApplication",
params={
"start": 500_000,
"cacheName": self.CACHE_NAME,
"interval": 100_000,
"valueSizeKb": 1
}
)
loader.start(clean=False)
loader.wait()
// loader stop was missed here %(
{noformat}
After:
{noformat}
loader.params = {"start": 500_000, "cacheName": self.CACHE_NAME, "interval":
100_000, "valueSizeKb": 1}
loader.run()
{noformat}
But found we have service's params duplication inside specs, so params change
has no effect.
So, I got rid of the service's params duplication inside the spec to make this
possible.
As a bonus, I simplified specs and get rid of spaghetti params :)
Fix confirmed by successful Jenkins run.
[~ivandasch], [~northdragon], please review the changes.
> Specs should use service's params instead of copying.
> -
>
> Key: IGNITE-14601
> URL: https://issues.apache.org/jira/browse/IGNITE-14601
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently a lot of params copied to spec.
> Need just to use {{self.service.xxx}} instead
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13670) Skip writing null-map and varlen table when possible
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-13670: - Assignee: Andrey Mashenkov > Skip writing null-map and varlen table when possible > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3, newbie > > h3. Motivation. > The nullmap is currently always written to the tuple layout for all columns > even if there are no nullable columns described in the schema. > The same is true and can be done for varlen table. > Seems, we can extend this idea to every single tuple and still have the > ability to compare key/value content fast as byte arrays. > Apparently, this will work for rows of same schema version, but we shouldn't > bother about the schema version, > because anyway, old row will be upgraded to the newer version before > comparison according to the live-schema concept. > h3. Description. > Let's skip an empty nullmap and write just a flag instead. > Let's skip an empty varlen table and write just a flag instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14088) Implement scalecube transport API over netty
[ https://issues.apache.org/jira/browse/IGNITE-14088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov reassigned IGNITE-14088: --- Assignee: Semyon Danilov > Implement scalecube transport API over netty > > > Key: IGNITE-14088 > URL: https://issues.apache.org/jira/browse/IGNITE-14088 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-66, ignite-3 > > scalecube has its own netty inside but it is idea to integrate our expanded > netty into it. It will help us to support more features like our own > handshake, marshalling etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14618) Increase stop timeout to 60 seconds
Anton Vinogradov created IGNITE-14618: - Summary: Increase stop timeout to 60 seconds Key: IGNITE-14618 URL: https://issues.apache.org/jira/browse/IGNITE-14618 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Graceful stops may take 10+ seconds, so we should increase the timeout to have no false-negative results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13019) Unexpected JOIN result when querying a single-node cluster
[
https://issues.apache.org/jira/browse/IGNITE-13019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326504#comment-17326504
]
Andrey Mashenkov commented on IGNITE-13019:
---
[~timonin.maksim],
As far as I understand, the fix is to log a warning if non-collocated tables
participated in JOIN and distributedJoins option is off.
I see multiple calls in a row that traverse AST tree for different purposes,
that impacts query latency.
{code:java}
map.partitioned(SplitterUtils.hasPartitionedTables(mapQry));
map.hasSubQueries(SplitterUtils.hasSubQueries(mapQry));
map.hasOuterJoinReplicatedPartitioned(SplitterUtils.hasOuterJoinReplicatedPartitioned(mapQry.from()));
if (map.isPartitioned() && !distributedJoins)
SplitterUtils.lookForPartitionedJoin(mapQry, null, log);
if (map.isPartitioned() && canExtractPartitions)
map.derivedPartitions(extractor.extract(mapQry));{code}
Why don't traverse AST tree only once here?
Or disable this check by default at least.
> Unexpected JOIN result when querying a single-node cluster
> --
>
> Key: IGNITE-13019
> URL: https://issues.apache.org/jira/browse/IGNITE-13019
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Check reproducer near,
> seems something wrong with pkey logic , if we change it - results will be ok.
> {code:java}
> @Test
> public void test() throws Exception {
> inlineSize = 10;
> startGrid(0);
> String t1 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno)\n" +
> " );";
> execSql(t1);
> String t2 = "CREATE TABLE emp\n" +
> " (\n" +
> "empno LONG,\n" +
> "ename VARCHAR,\n" +
> "job VARCHAR,\n" +
> "mgr INTEGER,\n" +
> "hiredate DATE,\n" +
> "sal LONG,\n" +
> "comm LONG,\n" +
> "deptno LONG,\n" +
> "CONSTRAINT pk_emp PRIMARY KEY (empno)\n" +
> " );";
> execSql(t2);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7839, 'KING', 'PRESIDENT', null,
> to_date('17-11-1981','dd-mm-'), 5000, null, 10);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values( 7698, 'BLAKE', 'MANAGER', 7839,
> to_date('1-5-1981','dd-mm-'), 2850, null, 30);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7782, 'CLARK', 'MANAGER', 7839,
> to_date('9-6-1981','dd-mm-'), 2450, null, 10);");
> List> vals1 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals1.size(), 2);
> List> vals2 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> //assertEquals(vals2.size(), 2); <--* uncomment for fail*
> execSql("drop table dept");
> String t3 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno, dname)\n" +
> " );";
> execSql(t3);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> List> vals11 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals11.size(), 2);
> List> vals22 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> a
[jira] [Commented] (IGNITE-14573) DML operations failure.
[
https://issues.apache.org/jira/browse/IGNITE-14573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326492#comment-17326492
]
Konstantin Orlov commented on IGNITE-14573:
---
Now it looks good to me.
> DML operations failure.
> ---
>
> Key: IGNITE-14573
> URL: https://issues.apache.org/jira/browse/IGNITE-14573
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As a result, insert with further read operations will fail.
> For example:
> {code:java}
> CREATE TABLE IF NOT EXISTS test (id INTEGER, a INTEGER);
> INSERT INTO test VALUES (1, 1), (2, 2), (3, 3), (4, NULL);"
> UPDATE test SET a=CASE WHEN id=1 THEN 7 ELSE NULL END WHERE id <= 2";
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14573) DML operations failure.
[
https://issues.apache.org/jira/browse/IGNITE-14573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326456#comment-17326456
]
Konstantin Orlov edited comment on IGNITE-14573 at 4/21/21, 12:36 PM:
--
[~zstan], overall looks good except that one problem I point out in PR.
was (Author: korlov):
> DML operations failure.
> ---
>
> Key: IGNITE-14573
> URL: https://issues.apache.org/jira/browse/IGNITE-14573
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As a result, insert with further read operations will fail.
> For example:
> {code:java}
> CREATE TABLE IF NOT EXISTS test (id INTEGER, a INTEGER);
> INSERT INTO test VALUES (1, 1), (2, 2), (3, 3), (4, NULL);"
> UPDATE test SET a=CASE WHEN id=1 THEN 7 ELSE NULL END WHERE id <= 2";
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14546) Calcite engine. MIN/MAX aggregates doesn't support string types
[
https://issues.apache.org/jira/browse/IGNITE-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326490#comment-17326490
]
Konstantin Orlov commented on IGNITE-14546:
---
[~zstan], LGTM!
> Calcite engine. MIN/MAX aggregates doesn't support string types
> ---
>
> Key: IGNITE-14546
> URL: https://issues.apache.org/jira/browse/IGNITE-14546
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> MIN/MAX aggregates doesn't support string types.
> e.g.
> {{CREATE TABLE TEST(val VARCHAR) }}
> {{INSERT INTO TEST VALUES ('A'), ('B'), ('C') }}
> {{ SELECT MIN(val), MAX(val) FROM TEST}}
> Test: {{src/test/sql/aggregate/aggregates/test_aggr_string.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14573) DML operations failure.
[
https://issues.apache.org/jira/browse/IGNITE-14573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326456#comment-17326456
]
Konstantin Orlov edited comment on IGNITE-14573 at 4/21/21, 12:31 PM:
--
was (Author: korlov):
[~zstan], overall looks good except that one problem I point out in PR.
> DML operations failure.
> ---
>
> Key: IGNITE-14573
> URL: https://issues.apache.org/jira/browse/IGNITE-14573
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As a result, insert with further read operations will fail.
> For example:
> {code:java}
> CREATE TABLE IF NOT EXISTS test (id INTEGER, a INTEGER);
> INSERT INTO test VALUES (1, 1), (2, 2), (3, 3), (4, NULL);"
> UPDATE test SET a=CASE WHEN id=1 THEN 7 ELSE NULL END WHERE id <= 2";
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14411) Define minimal set of cluster components and their lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326488#comment-17326488 ] Vyacheslav Koptilin commented on IGNITE-14411: -- Hi [~alapin], The patch looks good to me. Merged to the main branch. > Define minimal set of cluster components and their lifecycle > > > Key: IGNITE-14411 > URL: https://issues.apache.org/jira/browse/IGNITE-14411 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73 > Time Spent: 2h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14573) DML operations failure.
[
https://issues.apache.org/jira/browse/IGNITE-14573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326485#comment-17326485
]
Stanilovsky Evgeny commented on IGNITE-14573:
-
[~korlov] thanks ! fixed.
> DML operations failure.
> ---
>
> Key: IGNITE-14573
> URL: https://issues.apache.org/jira/browse/IGNITE-14573
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As a result, insert with further read operations will fail.
> For example:
> {code:java}
> CREATE TABLE IF NOT EXISTS test (id INTEGER, a INTEGER);
> INSERT INTO test VALUES (1, 1), (2, 2), (3, 3), (4, NULL);"
> UPDATE test SET a=CASE WHEN id=1 THEN 7 ELSE NULL END WHERE id <= 2";
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14612) Calcite. SELECT with CASE without boolean expression - fails.
[
https://issues.apache.org/jira/browse/IGNITE-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326477#comment-17326477
]
Stanilovsky Evgeny edited comment on IGNITE-14612 at 4/21/21, 12:21 PM:
[~korlov], [~tledkov-gridgain] guys plz check this fix ?
@ScriptRunnerTestsEnvironment(scriptsRoot = "src/test/sql", regex =
"/filter/test_constant_comparisons.test") tests are ok for now.
was (Author: zstan):
[~korlov], [~tledkov-gridgain] guys plz check this fix ?
> Calcite. SELECT with CASE without boolean expression - fails.
> -
>
> Key: IGNITE-14612
> URL: https://issues.apache.org/jira/browse/IGNITE-14612
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For example such expression - fails.
> {noformat}
> SELECT CASE WHEN 1 THEN 13 ELSE 12 END;{noformat}
> failed with:
> {code:java}
> class org.apache.ignite.IgniteException: Error at:
> test_constant_comparisons.test:91. sql: SELECT CASE WHEN 1 THEN 13 ELSE 12
> END;
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:518)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:93)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:214)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> plan query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:541)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:398)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:246)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:513)
> ... 3 more
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 8 to line 1, column 38: Expected a boolean type
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
> {code}
> and this work perfectly well:
> {noformat}
> SELECT CASE WHEN 1=1 THEN 13 ELSE 12 END;{noformat}
> a little reserch shows that calcite also fails in non boolean expression,
> root cause in
> SqlCaseOperator#checkOperandTypes and further check :
> {code:java}
> if (!SqlTypeUtil.inBooleanFamily(type){code} if we change this place,
> appropriate test
> {noformat}
> @Test void testCaseWhen2() {
> checkPlanEquals("SELECT CASE WHEN 1=1 THEN 13 ELSE 12 END");
> }{noformat}
> will work fine in calcite but will fail in ignite with janino error:
> {noformat}
> class org.apache.ignite.IgniteException: Line 3, Column 7: Not a boolean
> expression
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.compile(Commons.java:299)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:290)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.lambda$scalar$4(ExpressionFactoryImpl.java:241)
> at
> java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.scalar(ExpressionFactoryImpl.java:241)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.project(ExpressionFactoryImpl.java:198)
> at
> org.apache.ignite.internal.processors
[jira] [Updated] (IGNITE-14617) Calcite. Add opportunity to use NUMERIC in WHEN syntax.
[
https://issues.apache.org/jira/browse/IGNITE-14617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-14617:
Description:
Probably we need to support such kind of expressions:
{noformat}
SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
{noformat}
_WHEN 1=1_ - works correctly in such case. Additional info was given in [1]
[1] https://issues.apache.org/jira/browse/IGNITE-14612
was:
Probably we need to support such kind of expressions:
{noformat}
SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
{noformat}
_WHEN 1=1_ - works correctly in such case.
> Calcite. Add opportunity to use NUMERIC in WHEN syntax.
> ---
>
> Key: IGNITE-14617
> URL: https://issues.apache.org/jira/browse/IGNITE-14617
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
>
> Probably we need to support such kind of expressions:
> {noformat}
> SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
> {noformat}
> _WHEN 1=1_ - works correctly in such case. Additional info was given in [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-14612
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14411) Define minimal set of cluster components and their lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14411: - Labels: iep-73 ignite-3 (was: iep-73) > Define minimal set of cluster components and their lifecycle > > > Key: IGNITE-14411 > URL: https://issues.apache.org/jira/browse/IGNITE-14411 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73, ignite-3 > Time Spent: 2.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14617) Calcite. Add opportunity to use NUMERIC in WHEN syntax.
Stanilovsky Evgeny created IGNITE-14617:
---
Summary: Calcite. Add opportunity to use NUMERIC in WHEN syntax.
Key: IGNITE-14617
URL: https://issues.apache.org/jira/browse/IGNITE-14617
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Stanilovsky Evgeny
Probably we need to support such kind of expressions:
{noformat}
SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
{noformat}
_WHEN 1=1_ - works correctly in such case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14573) DML operations failure.
[
https://issues.apache.org/jira/browse/IGNITE-14573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326456#comment-17326456
]
Konstantin Orlov commented on IGNITE-14573:
---
[~zstan], overall looks good except that one problem I point out in PR.
> DML operations failure.
> ---
>
> Key: IGNITE-14573
> URL: https://issues.apache.org/jira/browse/IGNITE-14573
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As a result, insert with further read operations will fail.
> For example:
> {code:java}
> CREATE TABLE IF NOT EXISTS test (id INTEGER, a INTEGER);
> INSERT INTO test VALUES (1, 1), (2, 2), (3, 3), (4, NULL);"
> UPDATE test SET a=CASE WHEN id=1 THEN 7 ELSE NULL END WHERE id <= 2";
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14545) Calcite engine. Unicode literal not supported
[
https://issues.apache.org/jira/browse/IGNITE-14545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-14545:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Unicode literal not supported
> -
>
> Key: IGNITE-14545
> URL: https://issues.apache.org/jira/browse/IGNITE-14545
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Unicode literal not supported.
> e.g. {{SELECT }}
> Tests:
> {{aggregate/aggregates/test_aggr_string.test}}
> {{types/string/test_unicode.test_ignored}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14616) Replace the string variables that store the security password with array of char.
[ https://issues.apache.org/jira/browse/IGNITE-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14616: - Summary: Replace the string variables that store the security password with array of char. (was: eplace the string variables that store the security password with array of char.) > Replace the string variables that store the security password with array of > char. > - > > Key: IGNITE-14616 > URL: https://issues.apache.org/jira/browse/IGNITE-14616 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > > It is needed to replace the string variables that store the security password > with an array of characters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14616) eplace the string variables that store the security password with array of char.
Mikhail Petrov created IGNITE-14616: --- Summary: eplace the string variables that store the security password with array of char. Key: IGNITE-14616 URL: https://issues.apache.org/jira/browse/IGNITE-14616 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov It is needed to replace the string variables that store the security password with an array of characters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14615) Add support of grant/revoke commands for Ignite security plugin
Mikhail Petrov created IGNITE-14615: --- Summary: Add support of grant/revoke commands for Ignite security plugin Key: IGNITE-14615 URL: https://issues.apache.org/jira/browse/IGNITE-14615 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov It's needed to add support of grant/revoke commands for Ignite security plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14614) Add the ability to create security user with custom options
Mikhail Petrov created IGNITE-14614: --- Summary: Add the ability to create security user with custom options Key: IGNITE-14614 URL: https://issues.apache.org/jira/browse/IGNITE-14614 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov It is needed to add the ability to create security user with custom options that can be specific for security plugin implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14613) Mark CacheConfiguration.rebalanceDelay as deprecated.
Ilya Kasnacheev created IGNITE-14613: Summary: Mark CacheConfiguration.rebalanceDelay as deprecated. Key: IGNITE-14613 URL: https://issues.apache.org/jira/browse/IGNITE-14613 Project: Ignite Issue Type: Improvement Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Now that we have baseline topology and baseline auto-adjust, rebalance delay is rarely needed and does not see enough use/testing. See for example the mailing list thread where it became apparent it will disable historical rebalancing. Let's mark it as deprecated, target its removal in 3.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14612) Calcite. SELECT with CASE without boolean expression - fails.
Stanilovsky Evgeny created IGNITE-14612:
---
Summary: Calcite. SELECT with CASE without boolean expression -
fails.
Key: IGNITE-14612
URL: https://issues.apache.org/jira/browse/IGNITE-14612
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
For example such expression - fails.
{noformat}
SELECT CASE WHEN 1 THEN 13 ELSE 12 END;{noformat}
failed with:
{code:java}
class org.apache.ignite.IgniteException: Error at:
test_constant_comparisons.test:91. sql: SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:518)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:93)
at
org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:214)
at java.lang.Thread.run(Thread.java:748)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to plan
query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:541)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:398)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:246)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:513)
... 3 more
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 8 to line 1, column 38: Expected a boolean type
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
{code}
and this work perfectly well:
{noformat}
SELECT CASE WHEN 1=1 THEN 13 ELSE 12 END;{noformat}
a little reserch shows that calcite also fails in non boolean expression, root
cause in
SqlCaseOperator#checkOperandTypes and further check :
{code:java}
if (!SqlTypeUtil.inBooleanFamily(type){code} if we change this place,
appropriate test
{noformat}
@Test void testCaseWhen2() {
checkPlanEquals("SELECT CASE WHEN 1=1 THEN 13 ELSE 12 END");
}{noformat}
will work fine in calcite but will fail in ignite with janino error:
{noformat}
class org.apache.ignite.IgniteException: Line 3, Column 7: Not a boolean
expression
at
org.apache.ignite.internal.processors.query.calcite.util.Commons.compile(Commons.java:299)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:290)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.lambda$scalar$4(ExpressionFactoryImpl.java:241)
at
java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.scalar(ExpressionFactoryImpl.java:241)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.project(ExpressionFactoryImpl.java:198)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:195)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:102)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteProject.accept(IgniteProject.java:89)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:615)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:630)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:752)
at
org.apache.ignite.internal.processors.query.calc
[jira] [Updated] (IGNITE-14611) Implement error handling for public API based on error codes
[ https://issues.apache.org/jira/browse/IGNITE-14611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14611: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Implement error handling for public API based on error codes > > > Key: IGNITE-14611 > URL: https://issues.apache.org/jira/browse/IGNITE-14611 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Dev list discusstion [1] > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Error-handling-in-Ignite-3-td52269.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14611) Implement error handling for public API based on error codes
Alexey Scherbakov created IGNITE-14611: -- Summary: Implement error handling for public API based on error codes Key: IGNITE-14611 URL: https://issues.apache.org/jira/browse/IGNITE-14611 Project: Ignite Issue Type: Task Reporter: Alexey Scherbakov Fix For: 3.0 Dev list discusstion [1] [1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Error-handling-in-Ignite-3-td52269.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14552) Calcite engine. Alias for function CHARACTER_LENGTH
[
https://issues.apache.org/jira/browse/IGNITE-14552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-14552:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Alias for function CHARACTER_LENGTH
> ---
>
> Key: IGNITE-14552
> URL: https://issues.apache.org/jira/browse/IGNITE-14552
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Minor
>
> Currently the function to get the length of the string is named
> {{CHARACTER_LENGTH}}. It would be nice to have an alias {{LENGTH}} for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14610) BinaryBuilderReader doesn't supports reference (HANDLE) to collection
[
https://issues.apache.org/jira/browse/IGNITE-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14610:
--
Description:
*Steps to reproduce:*
1. Create object with two objects collection fields, e.g. List
2. Assign the reference of the one field to the second.
3. Serialize object to BinaryObject
4. Create BinaryObjectBuiler from the object.
5. Add/change any field except collections.
6. Try to build new BinaryObject form the builer
*Exception is thrown:*
{code:java}
class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
version: 2
at
org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
{code}
*Root cause:*
BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
handles to object are expected.
was:
Steps to reproduce:
1. Create object with two objects collection fields, e.g. List
2. Assign the reference of the one field to the second.
3. Serialize object to BinaryObject
4. Create BinaryObjectBuiler from the object.
5. Add/change any field except collections.
6. Try to build new BinaryObject form the builer
Exception is thrown:
{code:java}
class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
version: 2
at
org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
{code}
Root cause:
BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
handles to object are expected.
> BinaryBuilderReader doesn't supports reference (HANDLE) to collection
> -
>
> Key: IGNITE-14610
> URL: https://issues.apache.org/jira/browse/IGNITE-14610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.11
>
>
> *Steps to reproduce:*
> 1. Create object with two objects collection fields, e.g. List
> 2. Assign the reference of the one field to the second.
> 3. Serialize object to BinaryObject
> 4. Create BinaryObjectBuiler from the object.
> 5. Add/change any field except collections.
> 6. Try to build new BinaryObject form the builer
> *Exception is thrown:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 2
> at
> org.apache.ignite.internal.binary.BinaryUt
[jira] [Updated] (IGNITE-14610) BinaryBuilderReader doesn't supports reference (HANDLE) to collection
[
https://issues.apache.org/jira/browse/IGNITE-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14610:
--
Description:
Steps to reproduce:
1. Create object with two objects collection fields, e.g. List
2. Assign the reference of the one field to the second.
3. Serialize object to BinaryObject
4. Create BinaryObjectBuiler from the object.
5. Add/change any field except collections.
6. Try to build new BinaryObject form the builer
Exception is thrown:
{code:java}
class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
version: 2
at
org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
{code}
Root cause:
BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
handles to object are expected.
> BinaryBuilderReader doesn't supports reference (HANDLE) to collection
> -
>
> Key: IGNITE-14610
> URL: https://issues.apache.org/jira/browse/IGNITE-14610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
> Environment: Steps to reproduce:
> 1. Create object with two objects collection fields, e.g. List
> 2. Assign the reference of the one field to the second.
> 3. Serialize object to BinaryObject
> 4. Create BinaryObjectBuiler from the object.
> 5. Add/change any field except collections.
> 6. Try to build new BinaryObject form the builer
> Exception is thrown:
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 2
> at
> org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
> {code}
> Root cause:
> BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
> handles to object are expected.
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.11
>
>
> Steps to reproduce:
> 1. Create object with two objects collection fields, e.g. List
> 2. Assign the reference of the one field to the second.
> 3. Serialize object to BinaryObject
> 4. Create BinaryObjectBuiler from the object.
> 5. Add/change any field except collections.
> 6. Try to build new BinaryObject form the builer
> Exception is thrown:
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 2
>
[jira] [Created] (IGNITE-14610) BinaryBuilderReader doesn't supports reference (HANDLE) to collection
Taras Ledkov created IGNITE-14610:
-
Summary: BinaryBuilderReader doesn't supports reference (HANDLE)
to collection
Key: IGNITE-14610
URL: https://issues.apache.org/jira/browse/IGNITE-14610
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.10
Environment: Steps to reproduce:
1. Create object with two objects collection fields, e.g. List
2. Assign the reference of the one field to the second.
3. Serialize object to BinaryObject
4. Create BinaryObjectBuiler from the object.
5. Add/change any field except collections.
6. Try to build new BinaryObject form the builer
Exception is thrown:
{code:java}
class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
version: 2
at
org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
{code}
Root cause:
BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
handles to object are expected.
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14610) BinaryBuilderReader doesn't supports reference (HANDLE) to collection
[
https://issues.apache.org/jira/browse/IGNITE-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14610:
--
Environment: (was: Steps to reproduce:
1. Create object with two objects collection fields, e.g. List
2. Assign the reference of the one field to the second.
3. Serialize object to BinaryObject
4. Create BinaryObjectBuiler from the object.
5. Add/change any field except collections.
6. Try to build new BinaryObject form the builer
Exception is thrown:
{code:java}
class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
version: 2
at
org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
{code}
Root cause:
BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
handles to object are expected.
)
> BinaryBuilderReader doesn't supports reference (HANDLE) to collection
> -
>
> Key: IGNITE-14610
> URL: https://issues.apache.org/jira/browse/IGNITE-14610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.11
>
>
> Steps to reproduce:
> 1. Create object with two objects collection fields, e.g. List
> 2. Assign the reference of the one field to the second.
> 3. Serialize object to BinaryObject
> 4. Create BinaryObjectBuiler from the object.
> 5. Add/change any field except collections.
> 6. Try to build new BinaryObject form the builer
> Exception is thrown:
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 2
> at
> org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
> {code}
> Root cause:
> BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
> handles to object are expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14548) BinaryThreadLocalContext must be cleaned when client is closed
[
https://issues.apache.org/jira/browse/IGNITE-14548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14548:
--
Priority: Major (was: Critical)
> BinaryThreadLocalContext must be cleaned when client is closed
> --
>
> Key: IGNITE-14548
> URL: https://issues.apache.org/jira/browse/IGNITE-14548
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.11
>
>
> ThreadLocal {{BinaryThreadLocalContext#CTX}} must be cleaned when thin client
> and JDBC thin client are closed.
> Fail case: [Stack
> overflow|https://stackoverflow.com/questions/67086723/unable-to-remove-org-apache-ignite-internal-binary-binarythreadlocal-error-in-we?noredirect=1#comment118615654_67086723]
> Previous discussion: IGNITE-967
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[ https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-14441: -- Fix Version/s: (was: 2.11) > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy > > > Key: IGNITE-14441 > URL: https://issues.apache.org/jira/browse/IGNITE-14441 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14548) BinaryThreadLocalContext must be cleaned when client is closed
[
https://issues.apache.org/jira/browse/IGNITE-14548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14548:
--
Priority: Critical (was: Major)
> BinaryThreadLocalContext must be cleaned when client is closed
> --
>
> Key: IGNITE-14548
> URL: https://issues.apache.org/jira/browse/IGNITE-14548
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.11
>
>
> ThreadLocal {{BinaryThreadLocalContext#CTX}} must be cleaned when thin client
> and JDBC thin client are closed.
> Fail case: [Stack
> overflow|https://stackoverflow.com/questions/67086723/unable-to-remove-org-apache-ignite-internal-binary-binarythreadlocal-error-in-we?noredirect=1#comment118615654_67086723]
> Previous discussion: IGNITE-967
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[ https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov resolved IGNITE-14441. --- Release Note: (was: Write sensitive SQL information (queries and plans) to log according with the IGNITE_TO_STRING_INCLUDE_SENSITIVE system property. ) Resolution: Won't Fix Will be fixed with another way after change the sensitive data approach. > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy > > > Key: IGNITE-14441 > URL: https://issues.apache.org/jira/browse/IGNITE-14441 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
