[jira] [Commented] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848834#comment-17848834
]
Pavel Tupitsyn commented on IGNITE-22308:
-
Merged to master:
[a2cd44cd7873f5104253434f15eb740d98f20a51|https://github.com/apache/ignite/commit/a2cd44cd7873f5104253434f15eb740d98f20a51]
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22308:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848830#comment-17848830
]
Pavel Tupitsyn commented on IGNITE-22308:
-
Build fixed:
*
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetWindows?branch=pull%2F11359%2Fhead&buildTypeTab=overview&mode=builds
*
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux?branch=pull%2F11359%2Fhead&buildTypeTab=overview&mode=builds
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22309) Use name of the table instead of ID in IncompatibleSchemaException
Philipp Shergalis created IGNITE-22309: -- Summary: Use name of the table instead of ID in IncompatibleSchemaException Key: IGNITE-22309 URL: https://issues.apache.org/jira/browse/IGNITE-22309 Project: Ignite Issue Type: Improvement Reporter: Philipp Shergalis There is a TODO in the code. If the table was already dropped since the beginning of the operation, it's not trivial to get it's name. Nevertheless, ID of the table is meaningless for a user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22308:
Description:
{code}
C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
: error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a known
high severity vulnerability, https://github.com/advisories/GHSA-5crp-9r3c-p9vr
{code}
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
Pavel Tupitsyn created IGNITE-22308: --- Summary: .NET: Windows build fails due to vulnerable Newtonsoft.Json version Key: IGNITE-22308 URL: https://issues.apache.org/jira/browse/IGNITE-22308 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22288) ItTxResourcesVacuumTest may fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-22288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22288:
--
Description:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Scenario: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add the tx id to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state before cleanupCompletionTimestamp appears.
was:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Scenario: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add the tx id to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state.
> ItTxResourcesVacuumTest may fail with NPE
> -
>
> Key: IGNITE-22288
> URL: https://issues.apache.org/jira/browse/IGNITE-22288
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
> Stopping test:
> ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
> displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
> java.lang.NullPointerException java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildT
[jira] [Updated] (IGNITE-22288) ItTxResourcesVacuumTest may fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-22288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22288:
--
Description:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Scenario: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add the tx id to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state.
was:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Scenario: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add it to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state.
> ItTxResourcesVacuumTest may fail with NPE
> -
>
> Key: IGNITE-22288
> URL: https://issues.apache.org/jira/browse/IGNITE-22288
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
> Stopping test:
> ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
> displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
> java.lang.NullPointerException java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
[jira] [Updated] (IGNITE-22288) ItTxResourcesVacuumTest may fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-22288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22288:
--
Description:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Flow: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add it to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state.
was:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true
> ItTxResourcesVacuumTest may fail with NPE
> -
>
> Key: IGNITE-22288
> URL: https://issues.apache.org/jira/browse/IGNITE-22288
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
> Stopping test:
> ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
> displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
> java.lang.NullPointerException java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
> The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
> earlier than cleanup is completed, which causes tx recovery on RO tx with
> rollback outcome for RW tx that was committed and the abort of write intent.
> Flow: tx resource TTL is over, so we check the tx state meta (see
> VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
> commit partition), and we add it to collection that should be passed to
> persistent vacuumizer. Persistent vacuumizer erases the persistent state only
> if we are on the commit partition primary replica, but it doesn't check the
> presense of cleanupCompletionTimestamp, as it should. As a result, it erases
> the persistent state
[jira] [Updated] (IGNITE-22288) ItTxResourcesVacuumTest may fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-22288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22288:
--
Description:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Scenario: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add it to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state.
was:
{code:java}
[2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
Stopping test:
ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
java.lang.NullPointerException java.lang.NullPointerException
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
at
org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
The reason of failure is a bug in vacuum. Persistent tx state is vacuumized
earlier than cleanup is completed, which causes tx recovery on RO tx with
rollback outcome for RW tx that was committed and the abort of write intent.
Flow: tx resource TTL is over, so we check the tx state meta (see
VolatileTxStateMetaStorage#vacuum() ). There is commitPartId (because it's
commit partition), and we add it to collection that should be passed to
persistent vacuumizer. Persistent vacuumizer erases the persistent state only
if we are on the commit partition primary replica, but it doesn't check the
presense of cleanupCompletionTimestamp, as it should. As a result, it erases
the persistent state.
> ItTxResourcesVacuumTest may fail with NPE
> -
>
> Key: IGNITE-22288
> URL: https://issues.apache.org/jira/browse/IGNITE-22288
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [2024-05-20T10:02:21,361][INFO ][Test worker][ItTxResourcesVacuumTest] >>>
> Stopping test:
> ItTxResourcesVacuumTest#testCommitPartitionPrimaryChangesBeforeVacuum,
> displayName: testCommitPartitionPrimaryChangesBeforeVacuum(), cost: 11523ms.
> java.lang.NullPointerException java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.checkValueReadOnly(ItTxResourcesVacuumTest.java:803)
> at
> org.apache.ignite.internal.table.ItTxResourcesVacuumTest.testCommitPartitionPrimaryChangesBeforeVacuum(ItTxResourcesVacuumTest.java:536)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8127603?hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true]
> The reas
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-22089: --- Description: MVCC code has to be removed from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark was: MVCC code is to be removed from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > MVCC code has to be removed from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22158) Sql. incorrect result of NATURAL JOIN for BIGINTEGER column on condition
[
https://issues.apache.org/jira/browse/IGNITE-22158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-22158:
-
Assignee: Maksim Zhuravkov
> Sql. incorrect result of NATURAL JOIN for BIGINTEGER column on condition
>
>
> Key: IGNITE-22158
> URL: https://issues.apache.org/jira/browse/IGNITE-22158
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If we do natural join for tables containing BIGINT columns we have an
> incorrect empty result.
> {code:java}
> CREATE TABLE t1 (a INTEGER, b INTEGER)
> INSERT INTO t1 VALUES (1, 2)
> CREATE TABLE t2 (a BIGINT, c BIGINT)
> INSERT INTO t2 VALUES (1, 3), (2, 4)
> SELECT * FROM t1 NATURAL JOIN t2 - return nothing {code}
> reference - test/sql/join/natural/natural_join.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. Natural join Column name when encountered more than once must be ambiguous
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Summary: Sql. Natural join Column name when encountered more than once must
be ambiguous (was: Sql. Natural join Column name when encountered more than
once must be ambiguous.)
> Sql. Natural join Column name when encountered more than once must be
> ambiguous
> ---
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "i".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of two columns named "i" it is not possible to reference
> this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22149) Thin 3.0: Implement Table partition API
[ https://issues.apache.org/jira/browse/IGNITE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848640#comment-17848640 ] Mikhail Pochatkin commented on IGNITE-22149: Merged to main 1ae5d75b973ad8069af886e1dcfcfa2f9c801ab4 > Thin 3.0: Implement Table partition API > --- > > Key: IGNITE-22149 > URL: https://issues.apache.org/jira/browse/IGNITE-22149 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 3h 40m > Remaining Estimate: 0h > > Need to implement *org.apache.ignite.table.partition.PartitionManager* > interface in Thin Client. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. Natural join. Common column name is ambiguous if referenced directly
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Summary: Sql. Natural join. Common column name is ambiguous if referenced
directly (was: Sql. Natural join. Common column name is ambiguous.)
> Sql. Natural join. Common column name is ambiguous if referenced directly
> -
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns (columns used in a join condition)
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
> refers column "a" only once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. Natural join. Common column is ambiguous if referenced directly
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Summary: Sql. Natural join. Common column is ambiguous if referenced
directly (was: Sql. Natural join. Common column name is ambiguous if
referenced directly)
> Sql. Natural join. Common column is ambiguous if referenced directly
>
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns (columns used in a join condition)
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
> refers column "a" only once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. Natural join. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Summary: Sql. Natural join. Common column name is ambiguous. (was: Sql.
NATURAL JOIN. Common column name is ambiguous.)
> Sql. Natural join. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns (columns used in a join condition)
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
> refers column "a" only once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Description:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns (columns used in a join condition)
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
refers column "a" only once.
was:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns (columns used in join condition)
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
refers column "a" only once.
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns (columns used in a join condition)
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
> refers column "a" only once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Description:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns (columns used in join condition)
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
refers column "a" only once.
was:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
refers column "a" only once.
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns (columns used in join condition)
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
> refers column "a" only once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. Natural join Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Summary: Sql. Natural join Column name when encountered more than once must
be ambiguous. (was: Sql. NATURAL JOIN. Column name when encountered more than
once must be ambiguous.)
> Sql. Natural join Column name when encountered more than once must be
> ambiguous.
>
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "i".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of two columns named "i" it is not possible to reference
> this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Description:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
refers column "a" only once.
was:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be ambiguous because it relation t3 NATURAL JOIN t2
> refers column "a" only once.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Description:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of:
* common columns
* columns from t3 (excluding common columns)
* columns from t2 (excluding common columns)
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
So column "a" must not be
was:
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of
common column followed by columns from t3 (excluding common columns), followed
by columns from t2 (excluding common columns):
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of:
> * common columns
> * columns from t3 (excluding common columns)
> * columns from t2 (excluding common columns)
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
> So column "a" must not be
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Component/s: sql
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of
> common column followed by columns from t3 (excluding common columns),
> followed by columns from t2 (excluding common columns):
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
Maksim Zhuravkov created IGNITE-22307:
-
Summary: Sql. NATURAL JOIN. Common column name is ambiguous.
Key: IGNITE-22307
URL: https://issues.apache.org/jira/browse/IGNITE-22307
Project: Ignite
Issue Type: Bug
Reporter: Maksim Zhuravkov
Query:
{noformat}
statement ok
CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
statement ok
CREATE TABLE t2 (a INTEGER, c INTEGER)
query III
SELECT a, b, c FROM t3 NATURAL JOIN t2
1 2 3
# Error: Column 'A' is ambiguous
{noformat}
Result of a natural join between t2 and t3 consists of
common column followed by columns from t3 (excluding common columns), followed
by columns from t2 (excluding common columns):
{noformat}
# a, b - common columns
# c - column from t3
# there are no columns from t2
a, b, c
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Labels: ignite-3 (was: )
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of
> common column followed by columns from t3 (excluding common columns),
> followed by columns from t2 (excluding common columns):
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22307) Sql. NATURAL JOIN. Common column name is ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22307:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. NATURAL JOIN. Common column name is ambiguous.
> ---
>
> Key: IGNITE-22307
> URL: https://issues.apache.org/jira/browse/IGNITE-22307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Query:
> {noformat}
> statement ok
> CREATE TABLE t3 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> CREATE TABLE t2 (a INTEGER, c INTEGER)
> query III
> SELECT a, b, c FROM t3 NATURAL JOIN t2
>
> 1 2 3
> # Error: Column 'A' is ambiguous
> {noformat}
> Result of a natural join between t2 and t3 consists of
> common column followed by columns from t3 (excluding common columns),
> followed by columns from t2 (excluding common columns):
> {noformat}
> # a, b - common columns
> # c - column from t3
> # there are no columns from t2
> a, b, c
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL JOIN. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Summary: Sql. NATURAL JOIN. Column name when encountered more than once
must be ambiguous. (was: Sql. NATURAL join. Column name when encountered more
than once must be ambiguous.)
> Sql. NATURAL JOIN. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "i".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of two columns named "i" it is not possible to reference
> this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Fix Version/s: 3.0.0-beta2
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "i".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of two columns named "i" it is not possible to reference
> this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Description:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "i".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Since Q1 consists of two columns named "i" it is not possible to reference this
column.
was:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Since Q1 consists of two columns named "i" it is not possible to reference this
column.
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "i".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of two columns named "i" it is not possible to reference
> this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Description:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Since Q1 consists of two columns named "i" it is not possible to reference this
column.
was:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Since Q1 consists of columns two columns named "i" it is not possible to
reference this column.
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "I".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of two columns named "i" it is not possible to reference
> this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Description:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Since Q1 consists of columns two columns named "i" it is not possible to
reference this column.
was:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Q1 (columns: i, i) and Q2 (columns: i ) so natural join should not be possible
since it is not possible to distinguish "i".
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "I".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Since Q1 consists of columns two columns named "i" it is not possible to
> reference this column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Description:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Q1 (columns: i, i) and Q2 (columns: i ) so natural join should not be possible
since it is not possible to distinguish "i".
was:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Q1 (i, i) and Q2 (i) so natural join should not be possible since it is not
possible to distinguish "i".
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "I".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Q1 (columns: i, i) and Q2 (columns: i ) so natural join should not be
> possible since it is not possible to distinguish "i".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Description:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
*Query breakdown*
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
Q1 (i, i) and Q2 (i) so natural join should not be possible since it is not
possible to distinguish "i".
was:
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "I".
> *Query breakdown*
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
> Q1 (i, i) and Q2 (i) so natural join should not be possible since it is not
> possible to distinguish "i".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more then once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Summary: Sql. NATURAL join. Column name when encountered more then once
must be ambiguous. (was: Sql. NATURAL join. Column name must be ambiguous.)
> Sql. NATURAL join. Column name when encountered more then once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "I".
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22306) Sql. NATURAL join. Column name must be ambiguous.
Maksim Zhuravkov created IGNITE-22306:
-
Summary: Sql. NATURAL join. Column name must be ambiguous.
Key: IGNITE-22306
URL: https://issues.apache.org/jira/browse/IGNITE-22306
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Query:
{noformat}
select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i) natural
join (values (1)) t3(i);
{noformat}
Should return an error because the left table of the outermost join consists of
two columns named "I".
Q1 (wrapped in select )
{noformat}
select * from (
(values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
) q1
# returns i, i
# 1, 1
{noformat}
Q2 (wrapped in select )
{noformat}
select * from (
(values (1)) t3(i);
) q2
# returns i
# 1
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22306) Sql. NATURAL join. Column name when encountered more than once must be ambiguous.
[
https://issues.apache.org/jira/browse/IGNITE-22306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22306:
--
Summary: Sql. NATURAL join. Column name when encountered more than once
must be ambiguous. (was: Sql. NATURAL join. Column name when encountered more
then once must be ambiguous.)
> Sql. NATURAL join. Column name when encountered more than once must be
> ambiguous.
> -
>
> Key: IGNITE-22306
> URL: https://issues.apache.org/jira/browse/IGNITE-22306
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> select * from (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> natural join (values (1)) t3(i);
> {noformat}
> Should return an error because the left table of the outermost join consists
> of two columns named "I".
> Q1 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t1(i) join (values (1)) t2(i) on (t1.i=t2.i)
> ) q1
> # returns i, i
> # 1, 1
> {noformat}
> Q2 (wrapped in select )
> {noformat}
> select * from (
> (values (1)) t3(i);
> ) q2
> # returns i
> # 1
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22046:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD
was used in PartitionReplicaListener and other places connected to
PartitionReplicaListener that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to PartitionReplicaListener.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}} in
{{PartitionReplicaListener}} ({{getPrimaryReplica}}, {{awaitPrimaryReplica}})
must be changed to new methods which use {{ZonePartitionId}} (with tableId).
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD
was used in PartitionReplicaListener and other places connected to
PartitionReplicaListener that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to PartitionReplicaListener.
h3. Definition of done
All usages of PlacementDriver API with TablePartitionId in (getPrimaryReplica,
awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId
(with tableId).
> Change API usage of Placement driver in PartitionReplicaListener from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22046
> URL: https://issues.apache.org/jira/browse/IGNITE-22046
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> where PD was used in PartitionReplicaListener and other places connected to
> PartitionReplicaListener that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to PartitionReplicaListener.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}} in
> {{PartitionReplicaListener}} ({{getPrimaryReplica}}, {{awaitPrimaryReplica}})
> must be changed to new methods which use {{ZonePartitionId}} (with tableId).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22046: - Description: h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. h3. Definition of done All usages of PlacementDriver API with TablePartitionId in (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId (with tableId). was: h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. h3. Definition of done All usages of PlacementDriver API with TablePartitionId (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId (with tableId). > Change API usage of Placement driver in PartitionReplicaListener from > TablePartitionId to ZonePartitionId > - > > Key: IGNITE-22046 > URL: https://issues.apache.org/jira/browse/IGNITE-22046 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. Motivation > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > where PD was used in PartitionReplicaListener and other places connected to > PartitionReplicaListener that are described in the spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be > propagated to PartitionReplicaListener. > h3. Definition of done > All usages of PlacementDriver API with TablePartitionId in > (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which > use ZonePartitionId (with tableId). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22046: - Description: h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. h3. Definition of done All usages of PlacementDriver API with TablePartitionId (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId (with tableId). was: In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. > Change API usage of Placement driver in PartitionReplicaListener from > TablePartitionId to ZonePartitionId > - > > Key: IGNITE-22046 > URL: https://issues.apache.org/jira/browse/IGNITE-22046 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. Motivation > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > where PD was used in PartitionReplicaListener and other places connected to > PartitionReplicaListener that are described in the spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be > propagated to PartitionReplicaListener. > h3. Definition of done > All usages of PlacementDriver API with TablePartitionId (getPrimaryReplica, > awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId > (with tableId). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22305:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for
{{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}} was
used before. See spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to
change.
This will be the last place of PD API where {{TablePartitionId}} is used, so
after that we can get rid of decorator and rename {{getPrimaryReplicaForTable}}
and {{awaitPrimaryReplicaForTable}} and also we can move logic from the
decorator to LeaseTracker. Also {{LeaseTracker#tablePartIdToZoneIdProvider}}
could removed.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
new methods which use {{ZonePartitionId}} (with tableId). Also
{{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for
ClientPrimaryReplicaTracker where PD.getPrimaryReplica was used before. See
spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with
details about places to change.
This will be the last place of PD API where {{TablePartitionId}} is used, so
after that we can get rid of decorator and rename {{getPrimaryReplicaForTable}}
and {{awaitPrimaryReplicaForTable}} and also we can move logic from the
decorator to LeaseTracker. Also {{LeaseTracker#tablePartIdToZoneIdProvider}}
could removed.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
new methods which use {{ZonePartitionId}} (with tableId). Also
{{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
Mirza Aliev created IGNITE-22305:
Summary: Change API usage of Placement driver for
ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
Key: IGNITE-22305
URL: https://issues.apache.org/jira/browse/IGNITE-22305
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for
ClientPrimaryReplicaTracker where PD.getPrimaryReplica was used before. See
spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with
details about places to change.
This will be the last place of PD API where {{TablePartitionId}} is used, so
after that we can get rid of decorator and rename {{getPrimaryReplicaForTable}}
and {{awaitPrimaryReplicaForTable}} and also we can move logic from the
decorator to LeaseTracker. Also {{LeaseTracker#tablePartIdToZoneIdProvider}}
could removed.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
new methods which use {{ZonePartitionId}} (with tableId). Also
{{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848609#comment-17848609 ] Julia Bakulina edited comment on IGNITE-22089 at 5/22/24 1:34 PM: -- I have run Ignite Benchmarks locally after the deletion of the classes mentioned above. The throughput/latency plots are attached [^latency.png] [^throughput.png] was (Author: JIRAUSER294860): I have run Ignite Benchmarks locally after the deletion of the classes above. The throughput/latency plots are attached [^latency.png] [^throughput.png] > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > MVCC code is to be removed from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848609#comment-17848609 ] Julia Bakulina edited comment on IGNITE-22089 at 5/22/24 1:31 PM: -- I have run Ignite Benchmarks locally after the deletion of the classes above. The throughput/latency plots are attached [^latency.png] [^throughput.png] was (Author: JIRAUSER294860): I have run Ignite Benchmarks locally after the deleted of the classes above. The throughput/latency plots are attached [^latency.png] [^throughput.png] > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > MVCC code is to be removed from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Description: MVCC code is to be removed from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark was: To remove MVCC code from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > MVCC code is to be removed from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21913) Change API usage of Placement driver in Transaction module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21913:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
Transaction module where PD was used before. See spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to
change.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}, {{awaitPrimaryReplica}}) must be changed to new methods
which use {{ZonePartitionId}} (with tableId).
As a side effect, {{PlacementDriver}} events must be changed to
{{ZonePartitionId}} based events.
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
Transaction module where PD was used before. See spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to
change.
> Change API usage of Placement driver in Transaction module from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21913
> URL: https://issues.apache.org/jira/browse/IGNITE-21913
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in Transaction module where PD was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}, {{awaitPrimaryReplica}}) must be changed to new
> methods which use {{ZonePartitionId}} (with tableId).
> As a side effect, {{PlacementDriver}} events must be changed to
> {{ZonePartitionId}} based events.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848609#comment-17848609 ] Julia Bakulina edited comment on IGNITE-22089 at 5/22/24 1:23 PM: -- I have run Ignite Benchmarks locally after the deleted of the classes above. The throughput/latency plots are attached [^latency.png] [^throughput.png] was (Author: JIRAUSER294860): I have run Ignite Benchmarks locally after the deleted of the classes above. The throughput/latency plots are attached > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848609#comment-17848609 ] Julia Bakulina commented on IGNITE-22089: - I have run Ignite Benchmarks locally after the deleted of the classes above. The throughput/latency plots are attached > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Description: To remove MVCC code from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark was: To remove MVCC code from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark I have run Ignite Benchmarks locally after the deleted of the classes above. The throughput/latency plots are attached > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22304) Compute queue executor does not catch Throwable from user code
[ https://issues.apache.org/jira/browse/IGNITE-22304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22304: Description: See https://github.com/apache/ignite-3/blob/560c6da4afb067abe628d5d58872d9111ba477e1/modules/compute/src/main/java/org/apache/ignite/internal/compute/queue/QueueEntry.java#L78 We catch *Exception* instead of *Throwable*, so a job that throws certain types of errors can break Compute. > Compute queue executor does not catch Throwable from user code > -- > > Key: IGNITE-22304 > URL: https://issues.apache.org/jira/browse/IGNITE-22304 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See > https://github.com/apache/ignite-3/blob/560c6da4afb067abe628d5d58872d9111ba477e1/modules/compute/src/main/java/org/apache/ignite/internal/compute/queue/QueueEntry.java#L78 > We catch *Exception* instead of *Throwable*, so a job that throws certain > types of errors can break Compute. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22304) Compute queue executor does not catch Throwable from user code
Pavel Tupitsyn created IGNITE-22304: --- Summary: Compute queue executor does not catch Throwable from user code Key: IGNITE-22304 URL: https://issues.apache.org/jira/browse/IGNITE-22304 Project: Ignite Issue Type: Bug Components: compute Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19331) Sql. CAST with Boolean operations is failed.
[
https://issues.apache.org/jira/browse/IGNITE-19331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-19331:
-
Assignee: Andrey Mashenkov
> Sql. CAST with Boolean operations is failed.
>
>
> Key: IGNITE-19331
> URL: https://issues.apache.org/jira/browse/IGNITE-19331
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> SqlRunner tests are failed
> {noformat}
> /sql/test_boolean_cast.test_ignore
> {noformat}
> {noformat}
> query T
> SELECT CAST(CAST('1' AS float) AS BOOLEAN)
>
> true
> {noformat}
> {noformat}
> Not expected result at: (test_try_cast.test:150). [row=0, col=0,
> expected=true, actual=false]
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkEquals(SqlScriptRunner.java:635)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResultTuples(SqlScriptRunner.java:604)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResult(SqlScriptRunner.java:583)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:555)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22263) Sql. Avoid starting transaction for KV operation
[
https://issues.apache.org/jira/browse/IGNITE-22263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-22263:
--
Fix Version/s: 3.0.0-beta2
> Sql. Avoid starting transaction for KV operation
>
>
> Key: IGNITE-22263
> URL: https://issues.apache.org/jira/browse/IGNITE-22263
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, performance of KV put operation via SQL API is ~2 times worse than
> via KeyValueView API:
> {code:java}
> Benchmark (clusterSize) Mode CntScore Error Units
> InsertBenchmark.kvInsert 1 avgt 20 67.154 ± 4.266 us/op
> InsertBenchmark.sqlInsert 1 avgt 20 149.900 ± 9.679 us/op
> // these numbers acquired on MBP M3, commit c25f9fda.
> {code}
> This is caused by the fact that sql engine starts transaction explicitly if
> one was not provided by the user, thus not taking an advantage of single
> phase commit optimisation which is available for implicit transactions which
> touch only one partition.
> We can address the issue by postponing the moment of starting a transaction
> till execution phase. This will help to avoid starting an explicit
> transaction for simple KV cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22248) Creation of new tables in 1 node cluster stuck after 850+ tables
[
https://issues.apache.org/jira/browse/IGNITE-22248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-22248:
---
Description:
*Steps to reproduce:*
# Single node cluster with arguments "-Xms4096m", "-Xmx4096m"
# Create tables one by one up to 1000
*Expected:*
1000 tables are created.
*Actual:*
After 850+ tables the creation time is higher than 30 seconds or creation table
request fails.
!image-2024-05-15-13-22-40-059.png!
In the server logs continuous errors:
{code:java}
2024-05-15 04:11:58:116 +
[WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable
error during the request occurred (will be retried on the randomly selected
node) [request=WriteActionRequestImpl [command=[0, 9, 41, -126, -128, -36, -49,
-79, -50, -34, -57, 1], deserializedCommand=SafeTimeSyncCommandImpl
[safeTimeLong=112443150482997249], groupId=950_part_21], peer=Peer
[consistentId=TablesAmountCapacityTest_cluster_0, idx=0], newPeer=Peer
[consistentId=TablesAmountCapacityTest_cluster_0, idx=0]].
java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:368)
at
java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:377)
at
java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1097)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
at
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2874)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.util.concurrent.TimeoutException
... 7 more {code}
was:
*Steps to reproduce:*
# Single node cluster with arguments "-Xms4096m", "-Xmx4096m"
# Create tables one by one up to 1000
*Expected:*
1000 tables are created.
*Actual:*
After 850+ tables the creation time is higher than 30 seconds.
!image-2024-05-15-13-22-40-059.png!
In the server logs continuous errors:
{code:java}
2024-05-15 04:11:58:116 +
[WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable
error during the request occurred (will be retried on the randomly selected
node) [request=WriteActionRequestImpl [command=[0, 9, 41, -126, -128, -36, -49,
-79, -50, -34, -57, 1], deserializedCommand=SafeTimeSyncCommandImpl
[safeTimeLong=112443150482997249], groupId=950_part_21], peer=Peer
[consistentId=TablesAmountCapacityTest_cluster_0, idx=0], newPeer=Peer
[consistentId=TablesAmountCapacityTest_cluster_0, idx=0]].
java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:368)
at
java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:377)
at
java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1097)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
at
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2874)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.util.concurrent.TimeoutException
... 7 more {code}
> Creation of new tables in 1 node cluster stuck after 850+ tables
>
>
> Key: IGNITE-22248
> URL: https://issues.apache.org/jira/browse/IGNITE-22248
> Project: Ignite
> Issue Type: Bug
> Com
[jira] [Resolved] (IGNITE-21519) Improve test coverage for Java API for SQL
[ https://issues.apache.org/jira/browse/IGNITE-21519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich resolved IGNITE-21519. - Resolution: Invalid Sessions have been removed under IGNITE-21669 > Improve test coverage for Java API for SQL > --- > > Key: IGNITE-21519 > URL: https://issues.apache.org/jira/browse/IGNITE-21519 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > During implementation of Java API for SQL were added set of tests. However > added set of tests is insufficient. > Let's add the following test scenarios: > * Ability to recover an SQL session by session identifier during client > reconnection to the server. > * Statement properties could reload the session properties. > * The statement is immutable and can be used in different threads and > different sessions. > * Check the system's reaction to any actions with a closed session. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22303) Sql. Retry operation when plan gets outdated by the time of execution
[ https://issues.apache.org/jira/browse/IGNITE-22303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-22303: -- Fix Version/s: 3.0.0-beta2 > Sql. Retry operation when plan gets outdated by the time of execution > - > > Key: IGNITE-22303 > URL: https://issues.apache.org/jira/browse/IGNITE-22303 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In IGNITE-22263 start of the transaction was moved to execution phase. This > may cause situation, when plan gets outdated by the time of execution. Such > cases should be detected and handled properly (by retrying operation one more > time). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22303) Sql. Retry operation when plan gets outdated by the time of execution
[ https://issues.apache.org/jira/browse/IGNITE-22303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-22303: -- Labels: ignite-3 (was: ) > Sql. Retry operation when plan gets outdated by the time of execution > - > > Key: IGNITE-22303 > URL: https://issues.apache.org/jira/browse/IGNITE-22303 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > In IGNITE-22263 start of the transaction was moved to execution phase. This > may cause situation, when plan gets outdated by the time of execution. Such > cases should be detected and handled properly (by retrying operation one more > time). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22303) Sql. Retry operation when plan gets outdated by the time of execution
Konstantin Orlov created IGNITE-22303: - Summary: Sql. Retry operation when plan gets outdated by the time of execution Key: IGNITE-22303 URL: https://issues.apache.org/jira/browse/IGNITE-22303 Project: Ignite Issue Type: Bug Components: sql Reporter: Konstantin Orlov In IGNITE-22263 start of the transaction was moved to execution phase. This may cause situation, when plan gets outdated by the time of execution. Such cases should be detected and handled properly (by retrying operation one more time). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22302) Thin 3.0: Data Streamer with Receiver - add resultSubscriber support
[ https://issues.apache.org/jira/browse/IGNITE-22302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22302: Description: See TODOs with this ticket number. > Thin 3.0: Data Streamer with Receiver - add resultSubscriber support > > > Key: IGNITE-22302 > URL: https://issues.apache.org/jira/browse/IGNITE-22302 > Project: Ignite > Issue Type: Improvement > Components: streaming, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See TODOs with this ticket number. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22300) Adjust EventType names in EventLog
[ https://issues.apache.org/jira/browse/IGNITE-22300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22300: -- Assignee: Aleksandr > Adjust EventType names in EventLog > -- > > Key: IGNITE-22300 > URL: https://issues.apache.org/jira/browse/IGNITE-22300 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > I propose to adjust the names of EventTypes for EventLog, here is updated > types: > USER_AUTHENTICATION_SUCCESS, > USER_AUTHENTICATION_FAILURE > CLIENT_CONNECTION_ESTABLISHED, > CLIENT_CONNECTION_CLOSED. > We have to do that because now there is an inconsistency in naming for types. > Also, there is no way to see if the user has failed the authentication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22302) Thin 3.0: Data Streamer with Receiver - add resultSubscriber support
Pavel Tupitsyn created IGNITE-22302: --- Summary: Thin 3.0: Data Streamer with Receiver - add resultSubscriber support Key: IGNITE-22302 URL: https://issues.apache.org/jira/browse/IGNITE-22302 Project: Ignite Issue Type: Improvement Components: streaming, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Attachment: throughput.png latency.png > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark > I have run Ignite Benchmarks locally after the deleted of the classes above. > The throughput/latency plots are attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Description: To remove MVCC code from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark I have run Ignite Benchmarks locally after the deleted of the classes above. The throughput/latency plots are attached was: To remove MVCC code from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Attachments: latency.png, throughput.png > > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark > I have run Ignite Benchmarks locally after the deleted of the classes above. > The throughput/latency plots are attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22189) Display Expiry Policy information in the system view
[
https://issues.apache.org/jira/browse/IGNITE-22189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Davydov updated IGNITE-22189:
Description:
The {{CacheView#expiryPolicyFactory}} method returns the ExpiryPolicyFactory
string representation, which at this point is a simple className +@ + hashCode
in hex, that is default {{Object#toString()}} behaviour. This is not
informative for an end user of the API.
In addition, it is useful to have information about existing cache entries that
are about to expire (eligible for cache expiry policy).
{*}TODO{*}:
* To make the {{CacheView#expiryPolicyFactory}} method return readable,
human-oriented output, one should refactor the method or
{{Factory}} child classes to provide the cache expiry policy
setting in readable form with policy type and ttl.
* Within the cache group view ({{{}CacheGroupView{}}}), check the entries
presence eligible for expiry policy. It can be done with O(1) time complexity
for in-memory, and O(number of partitions) for persistent mode.
* Within the cache view ({{{}CacheView{}}}), check the entries presence
eligible for expiry policy. It can be done with O(logN) time complexity for
in-memory, and O(number of partitions) for persistent mode.
was:
The {{CacheView#expiryPolicyFactory}} method returns the ExpiryPolicyFactory
string representation, which at this point is a simple className +@ + hashCode
in hex, that is default {{Object#toString()}} behaviour. This is not
informative for an end user of the API.
In addition, it is useful to have information about existing cache entries that
are about to expire (eligible for cache expiry policy).
{*}TODO{*}:
* To make the {{CacheView#expiryPolicyFactory}} method return readable,
human-oriented output, one should refactor the method or
{{Factory}} child classes to provide the cache expiry policy
setting in readable form with policy type and ttl.
* Within the cache group view ({{CacheGroupView}}), check the entries presence
eligible for expiry policy. It can be done with O(1) time complexity for
in-memory, and O(number of partitions) for persistent mode.
> Display Expiry Policy information in the system view
>
>
> Key: IGNITE-22189
> URL: https://issues.apache.org/jira/browse/IGNITE-22189
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Davydov
>Assignee: Maksim Davydov
>Priority: Minor
> Labels: ise
>
> The {{CacheView#expiryPolicyFactory}} method returns the ExpiryPolicyFactory
> string representation, which at this point is a simple className +@ +
> hashCode in hex, that is default {{Object#toString()}} behaviour. This is not
> informative for an end user of the API.
> In addition, it is useful to have information about existing cache entries
> that are about to expire (eligible for cache expiry policy).
> {*}TODO{*}:
> * To make the {{CacheView#expiryPolicyFactory}} method return readable,
> human-oriented output, one should refactor the method or
> {{Factory}} child classes to provide the cache expiry policy
> setting in readable form with policy type and ttl.
> * Within the cache group view ({{{}CacheGroupView{}}}), check the entries
> presence eligible for expiry policy. It can be done with O(1) time complexity
> for in-memory, and O(number of partitions) for persistent mode.
> * Within the cache view ({{{}CacheView{}}}), check the entries presence
> eligible for expiry policy. It can be done with O(logN) time complexity for
> in-memory, and O(number of partitions) for persistent mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21835) MVCC code: final cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-21835: --- Description: Final cleanup of MVCC code. (was: To cleanup MvccUtils and enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS. Delete MVCC classes: * MvccVersion * MvccVersionImpl * MvccUpdateVersionAware. The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345) > MVCC code: final cleanup > > > Key: IGNITE-21835 > URL: https://issues.apache.org/jira/browse/IGNITE-21835 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Ilya Shishkov >Priority: Major > Labels: ise > Time Spent: 1h 10m > Remaining Estimate: 0h > > Final cleanup of MVCC code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22061:
-
Assignee: Pavel Pereslegin
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19103: -- Labels: ignite-3 (was: calcite3-required ignite-3) > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19103: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19103: -- Fix Version/s: 3.0.0-beta2 > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
Pavel Pereslegin created IGNITE-22301:
-
Summary: Test CatalogManagerSelfTest.alwaysWaitForActivationTime
is flaky
Key: IGNITE-22301
URL: https://issues.apache.org/jira/browse/IGNITE-22301
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
>From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
>fails with the following error ([test
>history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual&buildTypeId=&tab=testDetails&testNameId=-3345017748753084393&order=TEST_STATUS_DESC&branch_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__&itemsCount=50]).
{noformat}
org.mockito.exceptions.verification.TooManyActualInvocations:
testCommand.get();
Wanted 2 times:
-> at
org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
But was 3 times:
-> at
org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
-> at
org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
-> at
org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
{noformat}
This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22301:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
>
>
> Key: IGNITE-22301
> URL: https://issues.apache.org/jira/browse/IGNITE-22301
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
> fails with the following error ([test
> history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual&buildTypeId=&tab=testDetails&testNameId=-3345017748753084393&order=TEST_STATUS_DESC&branch_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__&itemsCount=50]).
> {noformat}
> org.mockito.exceptions.verification.TooManyActualInvocations:
> testCommand.get();
> Wanted 2 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
> But was 3 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> {noformat}
> This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-21418:
--
Assignee: Kirill Sizov
> ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is
> flaky
> ---
>
> Key: IGNITE-21418
> URL: https://issues.apache.org/jira/browse/IGNITE-21418
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.NullPointerException at
> org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8129077?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildTestsSection=true&expandBuildProblemsSection=true&expandCode+Inspection=true]
> Flaky rate is low.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848543#comment-17848543
]
Alexander Lapin commented on IGNITE-21418:
--
IGNITE-21572 is not the reason. There were failures after the fix.
> ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is
> flaky
> ---
>
> Key: IGNITE-21418
> URL: https://issues.apache.org/jira/browse/IGNITE-21418
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.NullPointerException at
> org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8129077?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildTestsSection=true&expandBuildProblemsSection=true&expandCode+Inspection=true]
> Flaky rate is low.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21418:
-
Description:
{code:java}
java.lang.NullPointerException at
org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
{code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8129077?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildTestsSection=true&expandBuildProblemsSection=true&expandCode+Inspection=true]
Flaky rate is low.
was:
{code:java}
java.lang.NullPointerException at
org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
{code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7814256?expandCode+Inspection=true&expandBuildProblemsSection=true&hideProblemsFromDependencies=false&expandBuildTestsSection=true&hideTestsFromDependencies=false&expandBuildChangesSection=true]
Flaky rate is low.
> ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is
> flaky
> ---
>
> Key: IGNITE-21418
> URL: https://issues.apache.org/jira/browse/IGNITE-21418
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.NullPointerException at
> org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8129077?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildTestsSection=true&expandBuildProblemsSection=true&expandCode+Inspection=true]
> Flaky rate is low.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22099) Delete TransactionDuplicateKeyException
[
https://issues.apache.org/jira/browse/IGNITE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848530#comment-17848530
]
Ignite TC Bot commented on IGNITE-22099:
{panel:title=Branch: [pull/11354/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11354/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7878183]]
* {color:#013220}IgniteCalciteTestSuite:
TableDmlIntegrationTest.testInsertDuplicateKey - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7878260&buildTypeId=IgniteTests24Java8_RunAll]
> Delete TransactionDuplicateKeyException
> ---
>
> Key: IGNITE-22099
> URL: https://issues.apache.org/jira/browse/IGNITE-22099
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Andrei Nadyktov
>Assignee: Andrei Nadyktov
>Priority: Trivial
> Labels: ise, newbie
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Delete TransactionDuplicateKeyException which is unused after MVCC code
> removal
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22300) Adjust EventType names in EventLog
Aleksandr created IGNITE-22300: -- Summary: Adjust EventType names in EventLog Key: IGNITE-22300 URL: https://issues.apache.org/jira/browse/IGNITE-22300 Project: Ignite Issue Type: Improvement Components: security Reporter: Aleksandr I propose to adjust the names of EventTypes for EventLog, here is updated types: USER_AUTHENTICATION_SUCCESS, USER_AUTHENTICATION_FAILURE CLIENT_CONNECTION_ESTABLISHED, CLIENT_CONNECTION_CLOSED. We have to do that because now there is an inconsistency in naming for types. Also, there is no way to see if the user has failed the authentication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21039) Network performance optimization
[
https://issues.apache.org/jira/browse/IGNITE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-21039:
--
Assignee: Roman Puchkovskiy
> Network performance optimization
>
>
> Key: IGNITE-21039
> URL: https://issues.apache.org/jira/browse/IGNITE-21039
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> I've run several test to find out the MessagingService performance metrics
> and that is what I've found:
> {noformat}
> TestBoolaMessage 139MB/sec WARD
> TestByteaMessage 132MB/sec WARD
> TestDoubleaMessage 102MB/sec WARD
> TestFloataMessage 132MB/sec WARD
> TestDoubleaMessage 130MB/sec WARD
> TestLongaMessage 131MB/sec WARD
> TestDoubleaMessage 131MB/sec WARD
> TestStringaMessage 280MB/sec WARD
> TestBoolMessage 11MB/sec WARD WARD
> TestByteMessage 12MB/sec WARD
> TestDoubleMessage 12MB/sec WARD
> TestFloatMessage 13MB/sec WARD
> TestIntMessage 12MB/sec WARD
> TestLongMessage 11MB/sec WARD
> TestShortMessage 12MB/sec WARD
> TestStringMessage 18MB/sec WARD
> TestBool20Message 15MB/sec WARD
> TestByte20Message 12MB/sec WARD
> TestDouble20Message 32MB/sec WARD
> TestFloat20Message 22MB/sec WARD
> TestInt20Message 13MB/sec WARD
> TestLong20Message 14MB/sec WARD
> TestShort20Message 14MB/sec WARD
> TestString20Message 65MB/sec WARD
> {noformat}
> All messages were sent in the same setup: 2 server nodes, connected with a
> *10GBit* interface. *Iperf3* (iperf3 --time 30 --zerocopy --client
> 192.168.1.126 --omit 3 --interval 1 --length 16384 --window 131072 --parallel
> 2 --json --version4) shows about *850MB/sec* network throughput. But the
> *best AI3* result was only {*}280MB/sec{*}. Upper results use 3 type of
> messages:
> 1. {*}TestaMessage{*}: array of 163840 elements (primitive, except
> String) of type .
> 2. {*}TestMessage{*}: single property (primitive, except String) of
> type
> 3. {*}Test20Message{*}: 20 property (primitive, except String) of type
>
> All the messages were sent in parallel from the single thread with the window
> of 100 messages (right after getting another first ack - the new message were
> sent).
> It was expected, that network utilization low for the very short messages
> (like 1 int or 20 int fields), but in comparison with the iperf3 results, the
> performance of MessagingService for 163KBytes messages was very low. It
> became significantly better only while sending huge array of strings (same
> string "{color:#067d17}Test string to check message service
> performance.{color}").
>
> I've run another butch of tests with 1KB byte[] property in the message in 1
> and 8 threads and without send window at all (each thread sends next message
> after getting the ack for the previous one):
> * *1 thread* and got *37 MBytes/sec*
> * *8 threads* and got *63 MBytes/sec* result.
> So I suppose there is pretty much contention.
> All messages were sent in the followin manner:
> {code:java}
> private void send(ClusterNode target, NetworkMessage msg) {
> messagingService.send(target, msg).handle((v, t) -> {
> if (t != null) {
> LOG.info("Error while sending huge message", t);
> }
> if (time() < timeout) {
> send(target, msg);
> }
> }{code}
>
>
> *
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22299) CDC resend doesn't send replicated earlier entries
[ https://issues.apache.org/jira/browse/IGNITE-22299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22299: Fix Version/s: 2.17 > CDC resend doesn't send replicated earlier entries > -- > > Key: IGNITE-22299 > URL: https://issues.apache.org/jira/browse/IGNITE-22299 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.17 > > > CDC resend is util to resend whole cache data from one cluster to another. It > logs cache entries to WAL and then the ignite-cdc process them. > But the ignite-cdc process has protection against looping entries. Replicated > entries has special mark - GridCacheVersionEx#drMap. By this flag ignite-cdc > filteres records and doesn't send them to receiver. > Then records replicated from other cluster are failed to be resend. > Steps to reproduce: > # put(0, 1) > # putAllConflict(0, 2) > # start cdc resend > # the record isn't sent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22299) CDC resend doesn't send replicated earlier entries
[ https://issues.apache.org/jira/browse/IGNITE-22299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22299: Summary: CDC resend doesn't send replicated earlier entries (was: CDC resend doesn't affect replicated earlier entries) > CDC resend doesn't send replicated earlier entries > -- > > Key: IGNITE-22299 > URL: https://issues.apache.org/jira/browse/IGNITE-22299 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > CDC resend is util to resend whole cache data from one cluster to another. It > logs cache entries to WAL and then the ignite-cdc process them. > But the ignite-cdc process has protection against looping entries. Replicated > entries has special mark - GridCacheVersionEx#drMap. By this flag ignite-cdc > filteres records and doesn't send them to receiver. > Then records replicated from other cluster are failed to be resend. > Steps to reproduce: > # put(0, 1) > # putAllConflict(0, 2) > # start cdc resend > # the record isn't sent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22299) CDC resend doesn't send replicated earlier entries
[ https://issues.apache.org/jira/browse/IGNITE-22299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22299: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > CDC resend doesn't send replicated earlier entries > -- > > Key: IGNITE-22299 > URL: https://issues.apache.org/jira/browse/IGNITE-22299 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.17 > > > CDC resend is util to resend whole cache data from one cluster to another. It > logs cache entries to WAL and then the ignite-cdc process them. > But the ignite-cdc process has protection against looping entries. Replicated > entries has special mark - GridCacheVersionEx#drMap. By this flag ignite-cdc > filteres records and doesn't send them to receiver. > Then records replicated from other cluster are failed to be resend. > Steps to reproduce: > # put(0, 1) > # putAllConflict(0, 2) > # start cdc resend > # the record isn't sent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22299) CDC resend doesn't send replicated earlier entries
[ https://issues.apache.org/jira/browse/IGNITE-22299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22299: Labels: ise (was: ) > CDC resend doesn't send replicated earlier entries > -- > > Key: IGNITE-22299 > URL: https://issues.apache.org/jira/browse/IGNITE-22299 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.17 > > > CDC resend is util to resend whole cache data from one cluster to another. It > logs cache entries to WAL and then the ignite-cdc process them. > But the ignite-cdc process has protection against looping entries. Replicated > entries has special mark - GridCacheVersionEx#drMap. By this flag ignite-cdc > filteres records and doesn't send them to receiver. > Then records replicated from other cluster are failed to be resend. > Steps to reproduce: > # put(0, 1) > # putAllConflict(0, 2) > # start cdc resend > # the record isn't sent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22299) CDC resend doesn't affect replicated earlier entries
[ https://issues.apache.org/jira/browse/IGNITE-22299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22299: Summary: CDC resend doesn't affect replicated earlier entries (was: CDC resend doesn't affect conflicted entries) > CDC resend doesn't affect replicated earlier entries > > > Key: IGNITE-22299 > URL: https://issues.apache.org/jira/browse/IGNITE-22299 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > CDC resend is util to resend whole cache data from one cluster to another. It > logs cache entries to WAL and then the ignite-cdc process them. > But the ignite-cdc process has protection against looping entries. Replicated > entries has special mark - GridCacheVersionEx#drMap. By this flag ignite-cdc > filteres records and doesn't send them to receiver. > Then records replicated from other cluster are failed to be resend. > Steps to reproduce: > # put(0, 1) > # putAllConflict(0, 2) > # start cdc resend > # the record isn't sent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22299) CDC resend doesn't affect conflicted entries
Maksim Timonin created IGNITE-22299: --- Summary: CDC resend doesn't affect conflicted entries Key: IGNITE-22299 URL: https://issues.apache.org/jira/browse/IGNITE-22299 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin CDC resend is util to resend whole cache data from one cluster to another. It logs cache entries to WAL and then the ignite-cdc process them. But the ignite-cdc process has protection against looping entries. Replicated entries has special mark - GridCacheVersionEx#drMap. By this flag ignite-cdc filteres records and doesn't send them to receiver. Then records replicated from other cluster are failed to be resend. Steps to reproduce: # put(0, 1) # putAllConflict(0, 2) # start cdc resend # the record isn't sent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22298) Node crashes if cache group name is empty
Nikita Amelchev created IGNITE-22298:
Summary: Node crashes if cache group name is empty
Key: IGNITE-22298
URL: https://issues.apache.org/jira/browse/IGNITE-22298
Project: Ignite
Issue Type: Bug
Affects Versions: 2.16
Reporter: Nikita Amelchev
Assignee: Nikita Amelchev
Reproducer:
{noformat}
ClientCacheConfiguration cacheCfg = new
ClientCacheConfiguration().setName("cache1").setGroupName("")
{noformat}
Exception:
{noformat}
2024-05-22 11:35:54.791 [ERROR][exchange-worker-#74][] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.AssertionError: 1 element is empty [cacheGroups.]]]
java.lang.AssertionError: 1 element is empty [cacheGroups.]
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.ensureAllNamesNotEmpty(MetricUtils.java:156)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.metricName(MetricUtils.java:56)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.metricGroupName(CacheGroupMetricsImpl.java:518)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.(CacheGroupMetricsImpl.java:99)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:271)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2497)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$getOrCreateCacheGroupContext$20(GridCacheProcessor.java:2170)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.util.InitializationProtector.protect(InitializationProtector.java:60)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2167)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:1994)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1929)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1804)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCachesIfPossible$17(GridCacheProcessor.java:1774)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1801)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCachesIfPossible(GridCacheProcessor.java:1772)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:998)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:884)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
~[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
[ignite-core-2.16.0.jar:2.16.0]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
[ignite-core-2.16.0.jar:2.16.0]
at java.base/java.lang.Thread.run(Thread.java:840) [?:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17232) Optimization of DeltaFilePageStore: write new pages directly to FilePageStore
[ https://issues.apache.org/jira/browse/IGNITE-17232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis reassigned IGNITE-17232: -- Assignee: Philipp Shergalis > Optimization of DeltaFilePageStore: write new pages directly to FilePageStore > - > > Key: IGNITE-17232 > URL: https://issues.apache.org/jira/browse/IGNITE-17232 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When creating *DelateFilePageStore* at checkpoint, we sort the list of all > dirty pages of the partition by *pageIdx*, write to disk the sorted list of > *pageIdx* (for *pageId -> pageIdx* binary lookup), the contents of the dirty > pages, and the current *pageIdx* of the page allocations. > I propose to optimize this a bit. > In *DelateFilePageStore*, store only changes in existing pages, and write all > new pages immediately to *FilePageStore*, so we will reduce the work for the > compacter (it will need to write less to the main partition file) and the > sorted list of *pageIdx* will be smaller. > Since the allocation index becomes logical (which is stored in the > *FilePageStore*) and depends on the first (newest) *DelateFilePageStore*, > then if the checkpoint is not completed, we will not lose or break anything > in the *FilePageStore* and on the new checkpoint we will write new pages on > over of those that we write on the unfinished previous checkpoint. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 "Boolean data type" and F571 "Truth values test" features for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 "Boolean datatype" and F571 "Truth values test" features for details. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 "Boolean data type" and F571 "Truth values test" features for > details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 "Boolean datatype" and F571 "Truth values test" features for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 and F503 features for details. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 "Boolean datatype" and F571 "Truth values test" features for > details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 feature for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 feature for details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
[ https://issues.apache.org/jira/browse/IGNITE-22297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-22297: -- Description: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 and F503 features for details. Let's support `IS UNKOWN` construction at least. was: As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. See SQL T032 feature for details. Let's support `IS UNKOWN` construction at least. > SQL. Support UNKNOWN boolean literal > > > Key: IGNITE-22297 > URL: https://issues.apache.org/jira/browse/IGNITE-22297 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As for now we do not support UNKNOWN boolean liternal within within IS clause > nor outside IS clause. > See SQL T032 and F503 features for details. > Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22297) SQL. Support UNKNOWN boolean literal
Andrey Mashenkov created IGNITE-22297: - Summary: SQL. Support UNKNOWN boolean literal Key: IGNITE-22297 URL: https://issues.apache.org/jira/browse/IGNITE-22297 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov As for now we do not support UNKNOWN boolean liternal within within IS clause nor outside IS clause. Let's support `IS UNKOWN` construction at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22296) Normalize --cmg-node and --meta-storage-node options in CLI
Aleksandr created IGNITE-22296: -- Summary: Normalize --cmg-node and --meta-storage-node options in CLI Key: IGNITE-22296 URL: https://issues.apache.org/jira/browse/IGNITE-22296 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr In https://issues.apache.org/jira/browse/IGNITE-22108 I've proposed to use --ms-node instead --meta-storage-node but it looks like this is misleading/confusing for the user. There is also --cmg-node option that does not self-explained. The proposal of this issue is to rename --cmg-node to --cluster-management-group and --meta-storage-node to --metastorage-group. The second proposal is to use comma-separated list to define nodes. Here is the example: --cluster-management-group node1, node2, node3 --metastorage-group node3, node5. This means that we remove the support for repeating options, the following command is not valid anymore: cluster init --cmg-node node1 --cmg-node node2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19331) Sql. CAST with Boolean operations is failed.
[
https://issues.apache.org/jira/browse/IGNITE-19331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848484#comment-17848484
]
Iurii Gerzhedovich commented on IGNITE-19331:
-
[~zstan] As I see we failed such queries with an error ' Cast function cannot
convert value of type FLOAT to type BOOLEAN' and it looks a valid.
I suggest to move the test case to test_boolean_cast.test with check the error
message
> Sql. CAST with Boolean operations is failed.
>
>
> Key: IGNITE-19331
> URL: https://issues.apache.org/jira/browse/IGNITE-19331
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> SqlRunner tests are failed
> {noformat}
> /sql/test_boolean_cast.test_ignore
> {noformat}
> {noformat}
> query T
> SELECT CAST(CAST('1' AS float) AS BOOLEAN)
>
> true
> {noformat}
> {noformat}
> Not expected result at: (test_try_cast.test:150). [row=0, col=0,
> expected=true, actual=false]
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkEquals(SqlScriptRunner.java:635)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResultTuples(SqlScriptRunner.java:604)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResult(SqlScriptRunner.java:583)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:555)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
