[jira] [Created] (IGNITE-16990) .NET: Thin 3.0: Add partition awareness to ExecuteColocated
Pavel Tupitsyn created IGNITE-16990: --- Summary: .NET: Thin 3.0: Add partition awareness to ExecuteColocated Key: IGNITE-16990 URL: https://issues.apache.org/jira/browse/IGNITE-16990 Project: Ignite Issue Type: Improvement Components: clients Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha5 1. Compute key hash on the client 2. Retrieve and maintain up-to-date partitionMap 2. Send the request directly to the target node if a connection exists -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15723) Implement a component factory
[ https://issues.apache.org/jira/browse/IGNITE-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15723: Description: Today we have many component (managers) that configure during start node. All of it created into the Ignite node constructor (IgniteImpl#IgniteImpl) and cannot be configurable: for example, no way to replace (or reconfigure) a Metastore for test. There is a recommendation to create the component factory, that can to create other managers itself. It should work as now by default, but in a test we will be able to rewrite some method for test purpose. In the ticket, need to create a default component factory and a method for IgniteManager which allow passing it. This new method does not need in ordinal cases, that means an internal interface for IgniteManager is required (IgniteManagerImpl). was: Today we have many component (managers) that configure during start node. All of it created into the Ignite node constructor (IgniteImpl#IgniteImpl) and cannot be configurable: for example, no way to replace (or reconfigure) a Metarore for test. There is a recommendation to create the component factory, that can to create other managers itself. It should work as now by default, but in a test we will be able to rewrite some method for test purpose. In the ticket, need to create a default component factory and a method for IgniteManager which allow passing it. This new method does not need in ordinal cases, that means an internal interface for IgniteManager is required (IgniteManagerImpl). > Implement a component factory > - > > Key: IGNITE-15723 > URL: https://issues.apache.org/jira/browse/IGNITE-15723 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Today we have many component (managers) that configure during start node. > All of it created into the Ignite node constructor (IgniteImpl#IgniteImpl) > and cannot be configurable: for example, no way to replace (or reconfigure) a > Metastore for test. > There is a recommendation to create the component factory, that can to create > other managers itself. It should work as now by default, but in a test we > will be able to rewrite some method for test purpose. > In the ticket, need to create a default component factory and a method for > IgniteManager which allow passing it. This new method does not need in > ordinal cases, that means an internal interface for IgniteManager is required > (IgniteManagerImpl). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16050) Common implementation for base mock dependent tests.
[ https://issues.apache.org/jira/browse/IGNITE-16050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-16050: --- Assignee: (was: Evgeny Stanilovsky) > Common implementation for base mock dependent tests. > > > Key: IGNITE-16050 > URL: https://issues.apache.org/jira/browse/IGNITE-16050 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > now we have _TableManagerTest_ which mocks useful inner classes, further mock > dependent tests implementation will raise copy-paste of such a code, we need > a common abstract class for such a purposes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
Nikolay Izhikov created IGNITE-16991:
Summary: SQL in clause with array arg fails since ignite 2.11
Key: IGNITE-16991
URL: https://issues.apache.org/jira/browse/IGNITE-16991
Project: Ignite
Issue Type: Bug
Reporter: Nikolay Izhikov
Reproducer.
Test passes on ignite-2.10 and fails on ignite-2.11
{code:java}
/** */
public class SqlInQueryTest extends GridCommonAbstractTest {
/** */
private static IgniteEx server;
/** {@inheritDoc} */
@Override protected void beforeTestsStarted() throws Exception {
super.beforeTestsStarted();
server = startGrid(0);
}
/** */
@Test
public void testSelectWithInClause() throws Exception {
sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY
KEY(ID, IID))", null);
for (int i = 0; i < 10; i++)
sql(
"INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)",
new Object[] {String.valueOf(i), String.valueOf(i % 3), "just
data"}
);
assertEquals(10, sql("SELECT ID, IID FROM T1", null).size());
// One ID inside IN clause.
assertEquals(1, sql(
"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
new Object[] {Arrays.asList("1").toArray(), "1"}
).size());
// Two ID inside IN clause.
assertEquals(2, sql(
"SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?",
new Object[] {"1"}
).size());
// Two ID inside IN clause. Pass as patameters.
//assertEquals(2, sql(
//"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
//new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size()
//);
}
/** */
private List> sql(String sqlText, Object[] args) {
return server.context().query().querySqlFields(
new
SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true
).getAll();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16013) Calcite engine. Introduce sort-with-limit physical relational operator
[
https://issues.apache.org/jira/browse/IGNITE-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16013:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Introduce sort-with-limit physical relational operator
> --
>
> Key: IGNITE-16013
> URL: https://issues.apache.org/jira/browse/IGNITE-16013
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite3-required
> Fix For: 2.14
>
> Time Spent: 7h 50m
> Remaining Estimate: 0h
>
> Currently, sort and limit are different physical relational operators, but in
> some cases, sort combined with a limit can be more effective. For example
> {{ORDER BY x LIMIT 1}} requires to store only one row and can be processed
> with {{O(rowsCount)}} operations. In general. {{ORDER BY x LIMIT m}} requires
> {{O(min(rowsCount, m))}} memory and have {{O(rowsCount * ln(min(rowsCount,
> m)))}} complexity.
> Since {{Limit}} node can't be moved below the {{Exchange}} node, {{ORDER BY x
> LIMIT m}} clause should produce two nodes: {{Limit}} node, with single
> distribution, and {{SortWithLimit}} node, which can be moved below the
> {{Exchange}} node and can reduce network traffic.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16013) Calcite engine. Introduce sort-with-limit physical relational operator
[
https://issues.apache.org/jira/browse/IGNITE-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16013:
---
Labels: calcite calcite3-required (was: calcite3-required)
> Calcite engine. Introduce sort-with-limit physical relational operator
> --
>
> Key: IGNITE-16013
> URL: https://issues.apache.org/jira/browse/IGNITE-16013
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite, calcite3-required
> Fix For: 2.14
>
> Time Spent: 7h 50m
> Remaining Estimate: 0h
>
> Currently, sort and limit are different physical relational operators, but in
> some cases, sort combined with a limit can be more effective. For example
> {{ORDER BY x LIMIT 1}} requires to store only one row and can be processed
> with {{O(rowsCount)}} operations. In general. {{ORDER BY x LIMIT m}} requires
> {{O(min(rowsCount, m))}} memory and have {{O(rowsCount * ln(min(rowsCount,
> m)))}} complexity.
> Since {{Limit}} node can't be moved below the {{Exchange}} node, {{ORDER BY x
> LIMIT m}} clause should produce two nodes: {{Limit}} node, with single
> distribution, and {{SortWithLimit}} node, which can be moved below the
> {{Exchange}} node and can reduce network traffic.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-15566) Calcite. Join with correlated subqueries returns wrong result.
[
https://issues.apache.org/jira/browse/IGNITE-15566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-15566:
Labels: calcite (was: calcite calcite3-required ignite-3)
> Calcite. Join with correlated subqueries returns wrong result.
> --
>
> Key: IGNITE-15566
> URL: https://issues.apache.org/jira/browse/IGNITE-15566
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Example from ScriptRunner :
> {noformat}
> query IIT
> SELECT * FROM test WHERE EXISTS(SELECT * FROM test2 WHERE test.a=test2.a AND
> test.b<>test2.c) AND NOT EXISTS(SELECT * FROM test2 WHERE test.a=test2.a AND
> test.b
> 122 b
> query IIT
> SELECT * FROM test WHERE NOT EXISTS(SELECT * FROM test2 WHERE test.a=test2.a
> AND test.b test.a=test2.a AND test.b>test2.c AND test2.a=12) ORDER BY a;
>
> 111 a
> 133 c
> {noformat}
> {noformat}
> /join/inner/test_eq_ineq_join.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
[
https://issues.apache.org/jira/browse/IGNITE-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538073#comment-17538073
]
Nikolay Izhikov commented on IGNITE-16991:
--
Introduced by 35b3528fa020fd5bf1dce03cd2fc63508c9912a3
IGNITE-13056 Move indexes from the indexing to the core module (closes #8490)
> SQL in clause with array arg fails since ignite 2.11
>
>
> Key: IGNITE-16991
> URL: https://issues.apache.org/jira/browse/IGNITE-16991
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Priority: Major
>
> Reproducer.
> Test passes on ignite-2.10 and fails on ignite-2.11
> {code:java}
> /** */
> public class SqlInQueryTest extends GridCommonAbstractTest {
> /** */
> private static IgniteEx server;
> /** {@inheritDoc} */
> @Override protected void beforeTestsStarted() throws Exception {
> super.beforeTestsStarted();
> server = startGrid(0);
> }
> /** */
> @Test
> public void testSelectWithInClause() throws Exception {
> sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY
> KEY(ID, IID))", null);
> for (int i = 0; i < 10; i++)
> sql(
> "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)",
> new Object[] {String.valueOf(i), String.valueOf(i % 3), "just
> data"}
> );
> assertEquals(10, sql("SELECT ID, IID FROM T1", null).size());
> // One ID inside IN clause.
> assertEquals(1, sql(
> "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
> new Object[] {Arrays.asList("1").toArray(), "1"}
> ).size());
> // Two ID inside IN clause.
> assertEquals(2, sql(
> "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?",
> new Object[] {"1"}
> ).size());
> // Two ID inside IN clause. Pass as patameters.
> //assertEquals(2, sql(
> //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
> //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size()
> //);
> }
> /** */
> private List> sql(String sqlText, Object[] args) {
> return server.context().query().querySqlFields(
> new
> SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true
> ).getAll();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16956) Tracing for rebalance logs
[ https://issues.apache.org/jira/browse/IGNITE-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-16956: --- Labels: ignite-3 (was: ) > Tracing for rebalance logs > -- > > Key: IGNITE-16956 > URL: https://issues.apache.org/jira/browse/IGNITE-16956 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > We need to implement a tracing of the rebalance process by the one trace id > to simplify issues' debugging in future. For this purposes we need to: > * create unique trace id, when rebalance triggered (update of replicas' > number, baseline changes) > * attach this trace id to all logs, connected with rebalance process > (https://issues.apache.org/jira/browse/IGNITE-16955). > The spreading of this trace id to the raft logs can be the most complex part > of the implementation. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16976) Replace ignite-cli with a new one
[ https://issues.apache.org/jira/browse/IGNITE-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-16976: --- Labels: ignite-3 (was: ) > Replace ignite-cli with a new one > - > > Key: IGNITE-16976 > URL: https://issues.apache.org/jira/browse/IGNITE-16976 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Drop existing ignite-cli module. > Change the documentation (installation process and commands description). > Provide the developer documentation (readme.md), so ignite developer can > understand how to add new commands and how to install the tool locally. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16985) Design table management flow
[ https://issues.apache.org/jira/browse/IGNITE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-16985: --- Labels: ignite-3 (was: ) > Design table management flow > > > Key: IGNITE-16985 > URL: https://issues.apache.org/jira/browse/IGNITE-16985 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > TBD -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16986) Incorrect GridCacheProcessor#stop parameters
[
https://issues.apache.org/jira/browse/IGNITE-16986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538157#comment-17538157
]
Ignite TC Bot commented on IGNITE-16986:
{panel:title=Branch: [pull/10025/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10025/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=6572119&buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect GridCacheProcessor#stop parameters
> -
>
> Key: IGNITE-16986
> URL: https://issues.apache.org/jira/browse/IGNITE-16986
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-16993) [Native Persistence 3.0] Consider replacing Checkpointer#isShutdownNow with an busy lock
Kirill Tkalenko created IGNITE-16993:
Summary: [Native Persistence 3.0] Consider replacing
Checkpointer#isShutdownNow with an busy lock
Key: IGNITE-16993
URL: https://issues.apache.org/jira/browse/IGNITE-16993
Project: Ignite
Issue Type: Task
Reporter: Kirill Tkalenko
Consider whether *Checkpointer#isShutdownNow* should be replaced with a busy
lock so that the code is more understandable without the use of
{code:java}
BooleanSupplier shutdownNow
{code}
in the linked code.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-16992) Partial node in ItIgniteNodeRestartTest should join the CMG
Aleksandr Polovtcev created IGNITE-16992:
Summary: Partial node in ItIgniteNodeRestartTest should join the
CMG
Key: IGNITE-16992
URL: https://issues.apache.org/jira/browse/IGNITE-16992
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
{{ItIgniteNodeRestartTest#testMetastorageStop}} test fails if the node, started
in {{startPartialNode}}, executes {{cmgManager.joinFuture()}}. For some reason,
it stops receiving Meta Storage revision updates after the Meta Storage node is
restarted.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
Pavel Tupitsyn created IGNITE-16994: --- Summary: .NET: Thin 3.0: Upgrade to SDK 6.0 Key: IGNITE-16994 URL: https://issues.apache.org/jira/browse/IGNITE-16994 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn .NET Core 3.1 LTS support ends in December 2022: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-16909) [Extensions] Release Ignite Spring and Cloud Extensions
[ https://issues.apache.org/jira/browse/IGNITE-16909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-16909. -- Resolution: Fixed > [Extensions] Release Ignite Spring and Cloud Extensions > > > Key: IGNITE-16909 > URL: https://issues.apache.org/jira/browse/IGNITE-16909 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > The following extenstions must be released: > - ignite-spring-data-ext > - ignite-spring-session-ext > - ignite-gce-ext > - ignite-aws-ext > - ignite-azure-ext > - ignite-zookeeper-ip-finder-ext -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
[ https://issues.apache.org/jira/browse/IGNITE-16994 ] Pavel Tupitsyn deleted comment on IGNITE-16994: - was (Author: ptupitsyn): [~isapego] please review. > .NET: Thin 3.0: Upgrade to SDK 6.0 > -- > > Key: IGNITE-16994 > URL: https://issues.apache.org/jira/browse/IGNITE-16994 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > .NET Core 3.1 LTS support ends in December 2022: > https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core > Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
[ https://issues.apache.org/jira/browse/IGNITE-16994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16994: Fix Version/s: (was: 3.0.0-alpha5) > .NET: Thin 3.0: Upgrade to SDK 6.0 > -- > > Key: IGNITE-16994 > URL: https://issues.apache.org/jira/browse/IGNITE-16994 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > .NET Core 3.1 LTS support ends in December 2022: > https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core > Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16939) ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-16939:
Description:
See
[https://ci.ignite.apache.org/viewLog.html?buildId=6560290&buildTypeId=ignite3_Test_RunUnitTests]
{code:java}
org.opentest4j.AssertionFailedError
org.opentest4j.AssertionFailedError: expected: but was:
at
org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68)
{code}
The branch is main with one commit which disables one test, so it's equivalent
to main branch in everything that concerns the failed test.
was:
See
[https://ci.ignite.apache.org/viewLog.html?buildId=6560290&buildTypeId=ignite3_Test_RunUnitTests]
{{org.opentest4j.AssertionFailedError: expected: but was: }}
{{ at
org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68)}}
The branch is main with one commit which disables one test, so it's equivalent
to main branch in everything that concerns the failed test.
> ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists
> is flaky
> --
>
> Key: IGNITE-16939
> URL: https://issues.apache.org/jira/browse/IGNITE-16939
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Reporter: Roman Puchkovskiy
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> See
> [https://ci.ignite.apache.org/viewLog.html?buildId=6560290&buildTypeId=ignite3_Test_RunUnitTests]
> {code:java}
> org.opentest4j.AssertionFailedError
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68)
> {code}
> The branch is main with one commit which disables one test, so it's
> equivalent to main branch in everything that concerns the failed test.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16930) .NET: Thin 3.0: Implement Compute.ExecuteColocated
[ https://issues.apache.org/jira/browse/IGNITE-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538206#comment-17538206 ] Igor Sapego commented on IGNITE-16930: -- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: Implement Compute.ExecuteColocated > -- > > Key: IGNITE-16930 > URL: https://issues.apache.org/jira/browse/IGNITE-16930 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Implement executeColocated without partition awareness (send the request > using the default connection, let the server route it to the correct node). > See IGNITE-16786 for a reference implementation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16930) .NET: Thin 3.0: Implement Compute.ExecuteColocated
[ https://issues.apache.org/jira/browse/IGNITE-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538210#comment-17538210 ] Pavel Tupitsyn commented on IGNITE-16930: - Merged to main: 32afeaaf02d8eb4d0d41f8cefb49263f52976ede > .NET: Thin 3.0: Implement Compute.ExecuteColocated > -- > > Key: IGNITE-16930 > URL: https://issues.apache.org/jira/browse/IGNITE-16930 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement executeColocated without partition awareness (send the request > using the default connection, let the server route it to the correct node). > See IGNITE-16786 for a reference implementation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16995) C++ Thin: Implement a RemoteFilter for ScanQuery
Igor Sapego created IGNITE-16995: Summary: C++ Thin: Implement a RemoteFilter for ScanQuery Key: IGNITE-16995 URL: https://issues.apache.org/jira/browse/IGNITE-16995 Project: Ignite Issue Type: New Feature Components: thin client Affects Versions: 2.13 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.14 Let's implement a RemoteFilter feature for C++ thin client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16877) C++ Thin: Implement ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-16877: - Description: Need to add the ScanQuery API to C++ thin client: * The ScanQuery must have a partition property: it may be used to do parallel initial data load to improve performance. was: Need to add the ScanQuery API to C++ thin client: * The ScanQuery must have a partition property: it may be used to do parallel initial data load to improve performance. * It would be nice for the ScanQuery to have a remote filter. Having a remote filter would improve the user experience. > C++ Thin: Implement ScanQuery > - > > Key: IGNITE-16877 > URL: https://issues.apache.org/jira/browse/IGNITE-16877 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > > Need to add the ScanQuery API to C++ thin client: > * The ScanQuery must have a partition property: it may be used to do parallel > initial data load to improve performance. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16996) Ignite C++: Implement a RemoteFilter for ScanQuery
Igor Sapego created IGNITE-16996: Summary: Ignite C++: Implement a RemoteFilter for ScanQuery Key: IGNITE-16996 URL: https://issues.apache.org/jira/browse/IGNITE-16996 Project: Ignite Issue Type: New Feature Components: platforms Affects Versions: 2.13 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.14 Let's implement a RemoteFilter feature for Ignite C++ (thick client). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
[ https://issues.apache.org/jira/browse/IGNITE-16994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16994: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Upgrade to SDK 6.0 > -- > > Key: IGNITE-16994 > URL: https://issues.apache.org/jira/browse/IGNITE-16994 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > > .NET Core 3.1 LTS support ends in December 2022: > https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core > Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16990) .NET: Thin 3.0: Add partition awareness to ExecuteColocated
[ https://issues.apache.org/jira/browse/IGNITE-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16990: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Add partition awareness to ExecuteColocated > --- > > Key: IGNITE-16990 > URL: https://issues.apache.org/jira/browse/IGNITE-16990 > Project: Ignite > Issue Type: Improvement > Components: clients >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-alpha5 > > > 1. Compute key hash on the client > 2. Retrieve and maintain up-to-date partitionMap > 2. Send the request directly to the target node if a connection exists -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16928) Thin 3.0: Implement sessions for Java client
[ https://issues.apache.org/jira/browse/IGNITE-16928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-16928: - Description: Let's implement local sessions for Java client. Sessions AKA logical connections are described in https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle. What needs to be implemented is: 1. On handshake server should generate a Connection ID and return it in HandshakeRsp; 2. Client should save a Connection ID and associate it with a node it connected to; 3. If disconnected, server should not at once clean up connection associated data but start timer instead. Timeout should be configurable by server config; 4. If client manages to send a proper ConnectionRestoreReq during timeout, the session is restored; 5. All results of all operations that were complete while physical connection is broken is stored within session data and sent back to client if connection is restored. was:Let's implemnt local sessions for Java client. > Thin 3.0: Implement sessions for Java client > > > Key: IGNITE-16928 > URL: https://issues.apache.org/jira/browse/IGNITE-16928 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Let's implement local sessions for Java client. > Sessions AKA logical connections are described in > https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle. > What needs to be implemented is: > 1. On handshake server should generate a Connection ID and return it in > HandshakeRsp; > 2. Client should save a Connection ID and associate it with a node it > connected to; > 3. If disconnected, server should not at once clean up connection associated > data but start timer instead. Timeout should be configurable by server config; > 4. If client manages to send a proper ConnectionRestoreReq during timeout, > the session is restored; > 5. All results of all operations that were complete while physical connection > is broken is stored within session data and sent back to client if connection > is restored. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16905) Sql. ClassCastException when deserialising TIMESTAMP literal
[
https://issues.apache.org/jira/browse/IGNITE-16905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538227#comment-17538227
]
Vladimir Steshin commented on IGNITE-16905:
---
[~korlov], I think I got it. But could we have some certain example like a
query?
> Sql. ClassCastException when deserialising TIMESTAMP literal
>
>
> Key: IGNITE-16905
> URL: https://issues.apache.org/jira/browse/IGNITE-16905
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: calcite, ignite-3
>
> The problem appears to be caused by an inconsistency of RelReader and
> RexBuilder: RelReader diserializes every integer value as a value of type
> Integer, but the RexBuilder assumes that for TIMESTAMP literal a value of
> type Long will be passed, and make the explicit cast:
> {code:java}
> // RexBuilder#clean(Object, RelDataType)
> case TIMESTAMP:
> if (o instanceof TimestampString) {
> return o;
> } else if (o instanceof Calendar) {
> if (!((Calendar) o).getTimeZone().equals(DateTimeUtils.UTC_ZONE)) {
> throw new AssertionError();
> }
> return TimestampString.fromCalendarFields((Calendar) o);
> } else {
> return TimestampString.fromMillisSinceEpoch((Long) o);
> } {code}
>
> Here is a stack trace:
> {noformat}
> Caused by: java.lang.ClassCastException: class java.lang.Integer cannot be
> cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in
> module java.base of loader 'bootstrap')
> at org.apache.calcite.rex.RexBuilder.clean(RexBuilder.java:1780)
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1558)
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1520)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:759)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuple(RelJsonReader.java:367)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuples(RelJsonReader.java:347)
> ... 24 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-16928) Thin 3.0: Implement sessions for Java client
[ https://issues.apache.org/jira/browse/IGNITE-16928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-16928: --- Assignee: Pavel Tupitsyn > Thin 3.0: Implement sessions for Java client > > > Key: IGNITE-16928 > URL: https://issues.apache.org/jira/browse/IGNITE-16928 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Let's implement local sessions for Java client. > Sessions AKA logical connections are described in > https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle. > What needs to be implemented is: > 1. On handshake server should generate a Connection ID and return it in > HandshakeRsp; > 2. Client should save a Connection ID and associate it with a node it > connected to; > 3. If disconnected, server should not at once clean up connection associated > data but start timer instead. Timeout should be configurable by server config; > 4. If client manages to send a proper ConnectionRestoreReq during timeout, > the session is restored; > 5. All results of all operations that were complete while physical connection > is broken is stored within session data and sent back to client if connection > is restored. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (IGNITE-16905) Sql. ClassCastException when deserialising TIMESTAMP literal
[ https://issues.apache.org/jira/browse/IGNITE-16905 ]
Vladimir Steshin deleted comment on IGNITE-16905:
---
was (Author: vladsz83):
[~korlov], I think I got it. But could we have some certain example like a
query?
> Sql. ClassCastException when deserialising TIMESTAMP literal
>
>
> Key: IGNITE-16905
> URL: https://issues.apache.org/jira/browse/IGNITE-16905
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: calcite, ignite-3
>
> The problem appears to be caused by an inconsistency of RelReader and
> RexBuilder: RelReader diserializes every integer value as a value of type
> Integer, but the RexBuilder assumes that for TIMESTAMP literal a value of
> type Long will be passed, and make the explicit cast:
> {code:java}
> // RexBuilder#clean(Object, RelDataType)
> case TIMESTAMP:
> if (o instanceof TimestampString) {
> return o;
> } else if (o instanceof Calendar) {
> if (!((Calendar) o).getTimeZone().equals(DateTimeUtils.UTC_ZONE)) {
> throw new AssertionError();
> }
> return TimestampString.fromCalendarFields((Calendar) o);
> } else {
> return TimestampString.fromMillisSinceEpoch((Long) o);
> } {code}
>
> Here is a stack trace:
> {noformat}
> Caused by: java.lang.ClassCastException: class java.lang.Integer cannot be
> cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in
> module java.base of loader 'bootstrap')
> at org.apache.calcite.rex.RexBuilder.clean(RexBuilder.java:1780)
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1558)
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1520)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:759)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuple(RelJsonReader.java:367)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuples(RelJsonReader.java:347)
> ... 24 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16897) Java thin: Implement IgniteSet
[ https://issues.apache.org/jira/browse/IGNITE-16897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538241#comment-17538241 ] Minkyu Kim commented on IGNITE-16897: - Hi. We wish Java Thin Client IgniteSet(Ignite & Gridgain Project) was also implemented with Partition Awareness for best performance like AtomicLong. Really appreciate it. > Java thin: Implement IgniteSet > -- > > Key: IGNITE-16897 > URL: https://issues.apache.org/jira/browse/IGNITE-16897 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.14 > > > Lets implement IgniteSet data structure for Java thin client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
[
https://issues.apache.org/jira/browse/IGNITE-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-16991.
--
Resolution: Won't Fix
> SQL in clause with array arg fails since ignite 2.11
>
>
> Key: IGNITE-16991
> URL: https://issues.apache.org/jira/browse/IGNITE-16991
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Priority: Major
>
> Reproducer.
> Test passes on ignite-2.10 and fails on ignite-2.11
> {code:java}
> /** */
> public class SqlInQueryTest extends GridCommonAbstractTest {
> /** */
> private static IgniteEx server;
> /** {@inheritDoc} */
> @Override protected void beforeTestsStarted() throws Exception {
> super.beforeTestsStarted();
> server = startGrid(0);
> }
> /** */
> @Test
> public void testSelectWithInClause() throws Exception {
> sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY
> KEY(ID, IID))", null);
> for (int i = 0; i < 10; i++)
> sql(
> "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)",
> new Object[] {String.valueOf(i), String.valueOf(i % 3), "just
> data"}
> );
> assertEquals(10, sql("SELECT ID, IID FROM T1", null).size());
> // One ID inside IN clause.
> assertEquals(1, sql(
> "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
> new Object[] {Arrays.asList("1").toArray(), "1"}
> ).size());
> // Two ID inside IN clause.
> assertEquals(2, sql(
> "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?",
> new Object[] {"1"}
> ).size());
> // Two ID inside IN clause. Pass as patameters.
> //assertEquals(2, sql(
> //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
> //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size()
> //);
> }
> /** */
> private List> sql(String sqlText, Object[] args) {
> return server.context().query().querySqlFields(
> new
> SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true
> ).getAll();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
[
https://issues.apache.org/jira/browse/IGNITE-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538244#comment-17538244
]
Nikolay Izhikov commented on IGNITE-16991:
--
Just copy of my investigation report from user list:
It seems, current behavior is correct, in general.
Looks like passing list of values as a parameter is common issue for JDBC SQL
queries [1] [2] [3].
Tried to find formal requirements in JDBC spec but didn’t find clear
description :)
Anyway, If you are interested in details:
H2 engine optimize IN clause of your query to Equals query, because it contains
only one item [4].
So in time Ignite receive filter it looks like «find string equals to array» -
this leads to the exception after [5].
Calcite engine behave a little bit different and returns empty results for the
same query.
Didn’t look deeper to explain this.
I will close ticket [6] as «Won’t fix».
Feel free to reopen it.
[1] https://www.baeldung.com/spring-jdbctemplate-in-list
[2]
https://stackoverflow.com/questions/45696465/how-to-pass-list-of-values-as-a-parameter-to-in-clause-using-jdbc-template
[3]
https://stackoverflow.com/questions/1327074/how-to-execute-in-sql-queries-with-springs-jdbctemplate-effectively
[4]
https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/expression/condition/ConditionIn.java#L129
[5] https://issues.apache.org/jira/browse/IGNITE-13056
[6] https://issues.apache.org/jira/browse/IGNITE-16991
> SQL in clause with array arg fails since ignite 2.11
>
>
> Key: IGNITE-16991
> URL: https://issues.apache.org/jira/browse/IGNITE-16991
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Priority: Major
>
> Reproducer.
> Test passes on ignite-2.10 and fails on ignite-2.11
> {code:java}
> /** */
> public class SqlInQueryTest extends GridCommonAbstractTest {
> /** */
> private static IgniteEx server;
> /** {@inheritDoc} */
> @Override protected void beforeTestsStarted() throws Exception {
> super.beforeTestsStarted();
> server = startGrid(0);
> }
> /** */
> @Test
> public void testSelectWithInClause() throws Exception {
> sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY
> KEY(ID, IID))", null);
> for (int i = 0; i < 10; i++)
> sql(
> "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)",
> new Object[] {String.valueOf(i), String.valueOf(i % 3), "just
> data"}
> );
> assertEquals(10, sql("SELECT ID, IID FROM T1", null).size());
> // One ID inside IN clause.
> assertEquals(1, sql(
> "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
> new Object[] {Arrays.asList("1").toArray(), "1"}
> ).size());
> // Two ID inside IN clause.
> assertEquals(2, sql(
> "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?",
> new Object[] {"1"}
> ).size());
> // Two ID inside IN clause. Pass as patameters.
> //assertEquals(2, sql(
> //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?",
> //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size()
> //);
> }
> /** */
> private List> sql(String sqlText, Object[] args) {
> return server.context().query().querySqlFields(
> new
> SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true
> ).getAll();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538245#comment-17538245
]
Vladimir Steshin commented on IGNITE-14961:
---
Does it correspond the standard? Why do we need this operator?
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
> Tests:
> {{function/date/test_extract_edge_cases.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-14961:
--
Priority: Minor (was: Major)
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Minor
> Labels: uncertain
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
> Tests:
> {{function/date/test_extract_edge_cases.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-14961:
--
Labels: uncertain (was: )
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
> Labels: uncertain
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
> Tests:
> {{function/date/test_extract_edge_cases.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538245#comment-17538245
]
Vladimir Steshin edited comment on IGNITE-14961 at 5/17/22 2:46 PM:
Does it correspond the standard? Why do we need this operator? There are the
intervals.
was (Author: vladsz83):
Does it correspond the standard? Why do we need this operator?
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Minor
> Labels: uncertain
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
> Tests:
> {{function/date/test_extract_edge_cases.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-15811) Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x
[ https://issues.apache.org/jira/browse/IGNITE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-15811: -- Priority: Minor (was: Major) > Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x > --- > > Key: IGNITE-15811 > URL: https://issues.apache.org/jira/browse/IGNITE-15811 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Minor > Labels: calcite, calcite2-required > > Let's rename the ignite-calcite module to ignite-sql-engine at Ignite 2.x -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-15811) Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x
[ https://issues.apache.org/jira/browse/IGNITE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538248#comment-17538248 ] Vladimir Steshin commented on IGNITE-15811: --- Looks controversial. It should be discussed I thing. Let's make it minor for now. > Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x > --- > > Key: IGNITE-15811 > URL: https://issues.apache.org/jira/browse/IGNITE-15811 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Minor > Labels: calcite, calcite2-required > > Let's rename the ignite-calcite module to ignite-sql-engine at Ignite 2.x -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-14955) Calcite engine. Not supported DATE/TIME functions
[
https://issues.apache.org/jira/browse/IGNITE-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538249#comment-17538249
]
Vladimir Steshin commented on IGNITE-14955:
---
There are analogues like WEEK(date), EXTRACT(timeUnit FROM datetime),
FLOOR(datetime TO timeUnit)
CEIL(datetime TO timeUnit). Looks like we nedd to check EXTRACT
> Calcite engine. Not supported DATE/TIME functions
> --
>
> Key: IGNITE-14955
> URL: https://issues.apache.org/jira/browse/IGNITE-14955
> Project: Ignite
> Issue Type: Improvement
>Reporter: Taras Ledkov
>Priority: Major
>
> Not supported DATE/TIME functions operation:
> - {{YEARWEEK}};
> - {{WEEKOFYEAR}};
> - {{DATE_PART}};
> - {{DATE_PART}};
> - {{DATE_TRUNC}};
> - {{EXTRACT(microseconds FROM d)}};
> - {{EXTRACT(milliseconds FROM d)}};
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16718) ItIgniteNodeRestartTest#testCfgGap is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538274#comment-17538274
]
Sergey Uttsel commented on IGNITE-16718:
LGTM
> ItIgniteNodeRestartTest#testCfgGap is flaky
> ---
>
> Key: IGNITE-16718
> URL: https://issues.apache.org/jira/browse/IGNITE-16718
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> ItIgniteNodeRestartTest#testCfgGap could be found in ignite-16362 branch.
> The reason of failure is null value instead of previously upserted key.
> With following (a bit simplified test: one table instead of two and one
> insertion instead of one hundred)
> {code:java}
> public void testCfgGap(TestInfo testInfo) {
> final int nodes = 4;
> for (int i = 0; i < nodes; i++) {
> startNode(testInfo, i);
> }
> createTableWithData(CLUSTER_NODES.get(0), "t1", nodes);
> String igniteName = CLUSTER_NODES.get(nodes - 1).name();
> log.info("Stopping the node.");
> IgnitionManager.stop(igniteName);
> checkTableWithData(CLUSTER_NODES.get(0), "t1");
> log.info("Starting the node.");
> Ignite newNode = IgnitionManager.start(igniteName, null,
> workDir.resolve(igniteName));
> CLUSTER_NODES.set(nodes - 1, newNode);
> checkTableWithData(CLUSTER_NODES.get(0), "t1");
> checkTableWithData(CLUSTER_NODES.get(nodes - 1), "t1");
> }
> private void checkTableWithData(Ignite ignite, String name) {
> ...
> for (int i = 0; i < 1; i++) {
> ...
> }
> }
> private void createTableWithData(Ignite ignite, String name, int replicas) {
> ...
> for (int i = 0; i < 1; i++) {
> ...
> }
> }{code}
> an inconsistent read is reproduced under the following flow:
> # table.keyValueView.put(k1)
> ## PartitionListener#handleUpsertCommand on Node B
> ## PartitionListener#handleUpsertCommand on Node C
> ## PartitionListener#handleUpsertCommand on Node D
> ## Please pay attention that upsert command wasn't handled on Node A, that's
> actually fine because B, C, D is a majority.
> # node D stop
> # nodeA.table.keyValueView().get(k1)
> ## PartitionListener#handleGetCommand on Node B // Means that B is a leader.
> # node D start
> ## PartitionListener#handleUpsertCommand on Node D // Inner raft rebalance
> # nodeA.table.keyValueView().get(k1)
> ## PartitionListener#handleGetCommand on Node B // Means that B is still a
> leader.
> # nodeD.table.keyValueView().get(k1)
> ## PartitionListener#handleGetCommand on Node *A* // Means that leader was
> changed to A and what's very important there was no handling upsert command
> on Node A.
> I've checked this by adding
> {code:java}
> private void handleUpsertCommand(UpsertCommand cmd) {
> System.out.println(">>> Upserted" +
> ((TxManagerImpl)txManager).clusterService.topologyService().localMember());
> ...
> } {code}
> and
> {code:java}
> private SingleRowResponse handleGetCommand(GetCommand cmd) {
> System.out.println(">>> Get" +
> ((TxManagerImpl)txManager).clusterService.topologyService().localMember());
>...
> } {code}
> Further investigation items might be:
> * Checking whether k1 upsert was committed on node A or not, meaning that
> committing and applying to state machine are different steps, and according
> to RAFT it's not valid to be a leader with missing committed entries.
> * Checking why leader was changed between reads.
> h4. UPD 1:
> >> Checking whether k1 upsert was committed on node A or not, meaning that
> >> committing and applying to state machine are different steps, and
> >> according to RAFT it's not valid to be a leader with missing committed
> >> entries.
> Checked. k1 upsert was committed on node A, so it's only unavailable within
> state machine. It also means that leader change to node A is valid.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538282#comment-17538282
]
Sergey Kadaner commented on IGNITE-9878:
I am getting the same error while retrieving a cache by name from the
SpringCacheManager:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
myCacheName
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356)
~[ignite-spring-2.9.1.jar:2.9.1]{noformat}
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538282#comment-17538282
]
Sergey Kadaner edited comment on IGNITE-9878 at 5/17/22 3:30 PM:
-
I am getting the same error while retrieving a cache by name from the
SpringCacheManager. What does this error mean?
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
myCacheName
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356)
~[ignite-spring-2.9.1.jar:2.9.1]{noformat}
was (Author: sergeykad):
I am getting the same error while retrieving a cache by name from the
SpringCacheManager:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
myCacheName
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356)
~[ignite-spring-2.9.1.jar:2.9.1]{noformat}
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-16897) Java thin: Implement IgniteSet
[ https://issues.apache.org/jira/browse/IGNITE-16897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538241#comment-17538241 ] Minkyu Kim edited comment on IGNITE-16897 at 5/17/22 8:14 PM: -- Hi. Java Thin Client IgniteSet (Ignite & Gridgain Project) also wants to be implemented with Partition Awareness for best performance. Really appreciate it. was (Author: pkgonan): Hi. We wish Java Thin Client IgniteSet(Ignite & Gridgain Project) was also implemented with Partition Awareness for best performance like AtomicLong. Really appreciate it. > Java thin: Implement IgniteSet > -- > > Key: IGNITE-16897 > URL: https://issues.apache.org/jira/browse/IGNITE-16897 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.14 > > > Lets implement IgniteSet data structure for Java thin client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16989) Annoying "Failed to ping node" warn messages in logs.
[ https://issues.apache.org/jira/browse/IGNITE-16989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16989: Labels: ise storage-engine (was: storage-engine) > Annoying "Failed to ping node" warn messages in logs. > - > > Key: IGNITE-16989 > URL: https://issues.apache.org/jira/browse/IGNITE-16989 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.13 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ise, storage-engine > > From user list [1], seems there is present annoying uninformative message in > logs, possible we neet to print only one of such a kind of messages and wrap > others into trace or debug severity? > [1] https://lists.apache.org/thread/1mkng62pco1nsjtdgm881m5ny9v3rogd > [~vladsz83] fyi too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16318) Empty binary object is incorrect written/read/modified
[
https://issues.apache.org/jira/browse/IGNITE-16318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538601#comment-17538601
]
Ignite TC Bot commented on IGNITE-16318:
{panel:title=Branch: [pull/10021/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10021/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Binary Objects{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=6572776]]
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerNonCompactSelfTest.emptyObjectBuilder[useBinaryArrays = false]
- PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerSelfTest.emptyObjectBuilder[useBinaryArrays = true] -
PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerSelfTest.emptyObjectBuilder[useBinaryArrays = false] -
PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerNonCompactSelfTest.emptyObjectBuilder[useBinaryArrays = true] -
PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerNonCompactSelfTest.emptyObjectBinarylizable[useBinaryArrays =
true] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerNonCompactSelfTest.emptyObjectBinarylizable[useBinaryArrays =
false] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerSelfTest.emptyObjectBinarylizable[useBinaryArrays = true] -
PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMarshallerSelfTest.emptyObjectBinarylizable[useBinaryArrays = false] -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6572878&buildTypeId=IgniteTests24Java8_RunAll]
> Empty binary object is incorrect written/read/modified
> --
>
> Key: IGNITE-16318
> URL: https://issues.apache.org/jira/browse/IGNITE-16318
> Project: Ignite
> Issue Type: Bug
> Components: binary, cache
>Reporter: Andrey Belyaev
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cache interceptor cause problem of missing binary scheme if sql insert
> contains only entry key fields and no one value field pass in query.
> There is exception happened if inside interceptor we try to make
> BinaryObjectBuilder from entry value BinaryObject (#toBuilder()) and then
> request builder for any field.
> Interceptor example:
> {code:java}
> new CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> // ...
> }
> } {code}
> It's a pretty serious error which currupt and shutdown grid.
> Code example:
> {code:java}
> LinkedHashMap fields = new LinkedHashMap<>();
> fields.put("A", "java.lang.String");
> fields.put("B", "java.lang.String");
> fields.put("C", "java.lang.String");
> Set keyFields = new LinkedHashSet<>();
> keyFields.add("A");
> CacheInterceptorAdapter cacheInterceptorAdapter = new
> CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> if (bValue == null || bValue.isEmpty()) {
> newValBuilder.setField("B", "Some value");
> }
> return newValBuilder.build();
> }
> };
> CacheConfiguration cacheConfiguration = new CacheConfiguration<>()
> .setName("TEST_CACHE")
> .setKeyConfiguration(new CacheKeyConfiguration()
> .setTypeName("TEST_CACHE_KEY")
> .setAffinityKeyFieldName("InternalId"))
> .setQueryEntities(Collections.singleton(new QueryEntity()
> .setTableName("TEST_CACHE")
> .setKeyType("TEST_CACHE_KEY")
> .setValueType("TEST_CACHE_VALUE")
> .setFields(fields)
> .setKeyFields(keyFields)))
> .setInterceptor(cacheInterceptorAdapter);
> IgniteConfiguration igniteConfiguration = new IgniteConfiguration()
> .setCacheConfiguration(cacheConfiguration);
> try (Ignite ignite = Ignition.start(igniteConfiguration)) {
> IgniteCache testCache = ignite.getOrCreateCache("TEST_CACHE");
> // putSql
> testCache.query(new SqlFieldsQuery("INSERT INTO TEST_CACHE (A) VALUES
> ('12
[jira] [Created] (IGNITE-16997) Design baseline concept
Alexander Lapin created IGNITE-16997: Summary: Design baseline concept Key: IGNITE-16997 URL: https://issues.apache.org/jira/browse/IGNITE-16997 Project: Ignite Issue Type: Task Reporter: Alexander Lapin TBD -- This message was sent by Atlassian Jira (v8.20.7#820007)
