[jira] [Commented] (IGNITE-20173) GridCacheCompoundIdentityFuture and it's ancestors initial cleanup
[
https://issues.apache.org/jira/browse/IGNITE-20173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751828#comment-17751828
]
Ignite TC Bot commented on IGNITE-20173:
{panel:title=Branch: [pull/10879/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10879/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7289509buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheCompoundIdentityFuture and it's ancestors initial cleanup
> --
>
> Key: IGNITE-20173
> URL: https://issues.apache.org/jira/browse/IGNITE-20173
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.16
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20177) GridCacheCompoundIdentityFuture's child-free descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20177: -- Fix Version/s: 2.16 > GridCacheCompoundIdentityFuture's child-free descendants initial cleanup > > > Key: IGNITE-20177 > URL: https://issues.apache.org/jira/browse/IGNITE-20177 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20177) GridCacheCompoundIdentityFuture's child-free descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20177: -- Ignite Flags: (was: Docs Required,Release Notes Required) > GridCacheCompoundIdentityFuture's child-free descendants initial cleanup > > > Key: IGNITE-20177 > URL: https://issues.apache.org/jira/browse/IGNITE-20177 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20177) GridCacheCompoundIdentityFuture child-free descendants initial cleanup
Anton Vinogradov created IGNITE-20177: - Summary: GridCacheCompoundIdentityFuture child-free descendants initial cleanup Key: IGNITE-20177 URL: https://issues.apache.org/jira/browse/IGNITE-20177 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20177) GridCacheCompoundIdentityFuture's child-free descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20177: -- Summary: GridCacheCompoundIdentityFuture's child-free descendants initial cleanup (was: GridCacheCompoundIdentityFuture child-free descendants initial cleanup) > GridCacheCompoundIdentityFuture's child-free descendants initial cleanup > > > Key: IGNITE-20177 > URL: https://issues.apache.org/jira/browse/IGNITE-20177 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20172) TX code cleanup scope #1 initial common cleanup
[
https://issues.apache.org/jira/browse/IGNITE-20172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751784#comment-17751784
]
Ignite TC Bot commented on IGNITE-20172:
{panel:title=Branch: [pull/10878/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10878/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7289281buildTypeId=IgniteTests24Java8_RunAll]
> TX code cleanup scope #1 initial common cleanup
> ---
>
> Key: IGNITE-20172
> URL: https://issues.apache.org/jira/browse/IGNITE-20172
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.16
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20176) GridNearTxAbstractEnlistFuture and it's descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20176: -- Ignite Flags: (was: Docs Required,Release Notes Required) > GridNearTxAbstractEnlistFuture and it's descendants initial cleanup > --- > > Key: IGNITE-20176 > URL: https://issues.apache.org/jira/browse/IGNITE-20176 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20176) GridNearTxAbstractEnlistFuture and it's descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20176: -- Fix Version/s: 2.16 > GridNearTxAbstractEnlistFuture and it's descendants initial cleanup > --- > > Key: IGNITE-20176 > URL: https://issues.apache.org/jira/browse/IGNITE-20176 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20176) GridNearTxAbstractEnlistFuture and it's descendants initial cleanup
Anton Vinogradov created IGNITE-20176: - Summary: GridNearTxAbstractEnlistFuture and it's descendants initial cleanup Key: IGNITE-20176 URL: https://issues.apache.org/jira/browse/IGNITE-20176 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20173) GridCacheCompoundIdentityFuture and it's ancestors initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-20173: - Assignee: Anton Vinogradov > GridCacheCompoundIdentityFuture and it's ancestors initial cleanup > -- > > Key: IGNITE-20173 > URL: https://issues.apache.org/jira/browse/IGNITE-20173 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20175) Revise and update java doc of MessagingService
[
https://issues.apache.org/jira/browse/IGNITE-20175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20175:
---
Description:
As a result of IGNITE-16948, we have gotten the parameter 'channelType'.
{code:java}
org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#send(java.lang.String,
org.apache.ignite.network.ChannelType, org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#respond(java.lang.String,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long)
org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long){code}
It affects guarantees about the ordering of messages, but it's not reflected in
the doc. Also, it's not clear which channel is used, if ChannelType is not
specified. We need to update the Java doc according to the changes.
was:
As a result of IGNITE-16948, we have gotten the parameter 'channelType'.
{code:java}
org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#send(java.lang.String,
org.apache.ignite.network.ChannelType, org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#respond(java.lang.String,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long)
org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long){code}
It affects guarantees about the ordering of messages, but it's not reflected in
the doc. Also, it's not clear which channel is used, if ChannelType is not
specified. We need to update the Java doc according to the changes.
> Revise and update java doc of MessagingService
> --
>
> Key: IGNITE-20175
> URL: https://issues.apache.org/jira/browse/IGNITE-20175
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> As a result of IGNITE-16948, we have gotten the parameter 'channelType'.
> {code:java}
> org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage)
> org.apache.ignite.network.MessagingService#send(java.lang.String,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage)
> org.apache.ignite.network.MessagingService#respond(java.lang.String,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage, long)
> org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage, long){code}
> It affects guarantees about the ordering of messages, but it's not reflected
> in the doc. Also, it's not clear which channel is used, if ChannelType is not
> specified. We need to update the Java doc according to the changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20175) Revise and update java doc of MessagingService
[
https://issues.apache.org/jira/browse/IGNITE-20175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20175:
---
Description:
As a result of IGNITE-16948, we have gotten the parameter 'channelType'.
{code:java}
org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#send(java.lang.String,
org.apache.ignite.network.ChannelType, org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#respond(java.lang.String,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long)
org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long){code}
It affects guarantees about the ordering of messages, but it's not reflected in
the doc. Also, it's not clear which channel is used, if ChannelType is not
specified. We need to update the Java doc according to the changes.
was:
As a result of IGNITE-16948, we got the parameter 'channelType'.
{code:java}
org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#send(java.lang.String,
org.apache.ignite.network.ChannelType, org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#respond(java.lang.String,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long)
org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long){code}
It affects guarantees about the ordering of messages, but it's not reflected in
the doc. Also, it's not clear which channel is used, if ChannelType is not
specified. We need to update the Java doc according to the changes.
> Revise and update java doc of MessagingService
> --
>
> Key: IGNITE-20175
> URL: https://issues.apache.org/jira/browse/IGNITE-20175
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> As a result of IGNITE-16948, we have gotten the parameter 'channelType'.
>
>
> {code:java}
> org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage)
> org.apache.ignite.network.MessagingService#send(java.lang.String,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage)
> org.apache.ignite.network.MessagingService#respond(java.lang.String,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage, long)
> org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
> org.apache.ignite.network.ChannelType,
> org.apache.ignite.network.NetworkMessage, long){code}
> It affects guarantees about the ordering of messages, but it's not reflected
> in the doc. Also, it's not clear which channel is used, if ChannelType is not
> specified. We need to update the Java doc according to the changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20175) Revise and update java doc of MessagingService
Ivan Gagarkin created IGNITE-20175:
--
Summary: Revise and update java doc of MessagingService
Key: IGNITE-20175
URL: https://issues.apache.org/jira/browse/IGNITE-20175
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
As a result of IGNITE-16948, we got the parameter 'channelType'.
{code:java}
org.apache.ignite.network.MessagingService#send(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#send(java.lang.String,
org.apache.ignite.network.ChannelType, org.apache.ignite.network.NetworkMessage)
org.apache.ignite.network.MessagingService#respond(java.lang.String,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long)
org.apache.ignite.network.MessagingService#invoke(org.apache.ignite.network.ClusterNode,
org.apache.ignite.network.ChannelType,
org.apache.ignite.network.NetworkMessage, long){code}
It affects guarantees about the ordering of messages, but it's not reflected in
the doc. Also, it's not clear which channel is used, if ChannelType is not
specified. We need to update the Java doc according to the changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20134) Only allow changing type of indexed column when indexed values representation remains the same
[ https://issues.apache.org/jira/browse/IGNITE-20134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751740#comment-17751740 ] Roman Puchkovskiy commented on IGNITE-20134: We should carefully consider whether we can allow integral->decimal change in this context > Only allow changing type of indexed column when indexed values representation > remains the same > -- > > Key: IGNITE-20134 > URL: https://issues.apache.org/jira/browse/IGNITE-20134 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When an attempt to change type of a column that is included in an index is > made, this should only be permitted if the representation of the column > values in the index will remain unchanged (and, hence, index rebuild will not > be needed). > The following changes are acceptable: > * integral->integral (as integral types are represented as varints) > * integral->decimal (with enough precision) and float->double for SORTED > indices where the ordering remains the same > * integral->decimal and decimal->decimal (with enough precision) for HASH > indices (requires IGNITE-20133) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20133) Compute hashes for integral/decimal columns in a stable way
[
https://issues.apache.org/jira/browse/IGNITE-20133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751739#comment-17751739
]
Roman Puchkovskiy commented on IGNITE-20133:
It should be reconsidered whether we can support integral->decimal in this
context
> Compute hashes for integral/decimal columns in a stable way
> ---
>
> Key: IGNITE-20133
> URL: https://issues.apache.org/jira/browse/IGNITE-20133
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The idea is to make hash computation for integral and decimal types satisfy
> the following property: if a column type is changed from an integral to a
> decimal type, the hashes for values that are already stored remain the same.
> This will allow us to permit chaning type (integral -> decimal and decimal ->
> longer decimal) of a column that is included in a HASH index.
> A hash that has this property is the following function:
> hash(val.toString(TRIM_TRAILING_ZEROS)). For instance, for 1 it will be
> hash("1"), for 1.000 it will also be hash("1"), but for 1.23 it will give
> hash("1.23").
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20174) CacheDistributedGetFutureAdapter and it's descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20174: -- Ignite Flags: (was: Docs Required,Release Notes Required) > CacheDistributedGetFutureAdapter and it's descendants initial cleanup > - > > Key: IGNITE-20174 > URL: https://issues.apache.org/jira/browse/IGNITE-20174 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20173) GridCacheCompoundIdentityFuture and it's ancestors initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20173: -- Ignite Flags: (was: Docs Required,Release Notes Required) > GridCacheCompoundIdentityFuture and it's ancestors initial cleanup > -- > > Key: IGNITE-20173 > URL: https://issues.apache.org/jira/browse/IGNITE-20173 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20173) GridCacheCompoundIdentityFuture and it's ancestors initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20173: -- Fix Version/s: 2.16 > GridCacheCompoundIdentityFuture and it's ancestors initial cleanup > -- > > Key: IGNITE-20173 > URL: https://issues.apache.org/jira/browse/IGNITE-20173 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20174) CacheDistributedGetFutureAdapter and it's descendants initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20174: -- Fix Version/s: 2.16 > CacheDistributedGetFutureAdapter and it's descendants initial cleanup > - > > Key: IGNITE-20174 > URL: https://issues.apache.org/jira/browse/IGNITE-20174 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20174) CacheDistributedGetFutureAdapter and it's descendants initial cleanup
Anton Vinogradov created IGNITE-20174: - Summary: CacheDistributedGetFutureAdapter and it's descendants initial cleanup Key: IGNITE-20174 URL: https://issues.apache.org/jira/browse/IGNITE-20174 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20173) GridCacheCompoundIdentityFuture and it's ancestors initial cleanup
Anton Vinogradov created IGNITE-20173: - Summary: GridCacheCompoundIdentityFuture and it's ancestors initial cleanup Key: IGNITE-20173 URL: https://issues.apache.org/jira/browse/IGNITE-20173 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20172) TX code cleanup scope #1 initial common cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20172: -- Fix Version/s: 2.16 > TX code cleanup scope #1 initial common cleanup > --- > > Key: IGNITE-20172 > URL: https://issues.apache.org/jira/browse/IGNITE-20172 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20172) TX code cleanup scope #1 initial common cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20172: -- Ignite Flags: (was: Docs Required,Release Notes Required) > TX code cleanup scope #1 initial common cleanup > --- > > Key: IGNITE-20172 > URL: https://issues.apache.org/jira/browse/IGNITE-20172 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20158) CLI: cluster/node config update is not user friendly
[
https://issues.apache.org/jira/browse/IGNITE-20158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-20158:
---
Description:
The configuration update process can be painful because of the way CLI parses
the command line. For example,
{code:java}
[defaultNode]> cluster config update -u http://localhost:10300
"{aipersist.regions: [{name: persistent_region,size: 2560
0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
com.typesafe.config.ConfigException$Parse: String: 1: Key '"{aipersist.regions:
[{name: persistent_region,size: 25600}],aimem.regions: [{name:
btree_volatile_region,maxSize: 25600}]}"' may not be followed by token: end
of file
{code}
There is no way to understand what is going wrong.
I suggest improving the error text and showing the correct command example.
And we have to investigate the root cause of the issue and create a follow-up
ticket to fix the way CLI parses the command line. I expect the example command
to be valid.
We have to provide user-friendly response in any case.
was:
The configuration update process can be painful because of the way CLI parses
the command line. For example,
{code:java}
[defaultNode]> cluster config update -u http://localhost:10300
"{aipersist.regions: [{name: persistent_region,size: 2560
0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
com.typesafe.config.ConfigException$Parse: String: 1: Key '"{aipersist.regions:
[{name: persistent_region,size: 25600}],aimem.regions: [{name:
btree_volatile_region,maxSize: 25600}]}"' may not be followed by token: end
of file
{code}
There is no way to understand what is going wrong.
I suggest improving the error text and showing the correct command example.
And we have to investigate the root cause of the issue and create a follow-up
ticket to fix the way CLI parses the command line. I expect the example command
to be valid.
> CLI: cluster/node config update is not user friendly
>
>
> Key: IGNITE-20158
> URL: https://issues.apache.org/jira/browse/IGNITE-20158
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> The configuration update process can be painful because of the way CLI parses
> the command line. For example,
> {code:java}
> [defaultNode]> cluster config update -u http://localhost:10300
> "{aipersist.regions: [{name: persistent_region,size: 2560
> 0}],aimem.regions: [{name: btree_volatile_region,maxSize: 25600}]}"
> IGN-CMN-65535 Trace ID: 5430a4a7-b24d-4861-89aa-fdb84a17b199
> com.typesafe.config.ConfigException$Parse: String: 1: Key
> '"{aipersist.regions: [{name: persistent_region,size:
> 25600}],aimem.regions: [{name: btree_volatile_region,maxSize:
> 25600}]}"' may not be followed by token: end of file
> {code}
> There is no way to understand what is going wrong.
> I suggest improving the error text and showing the correct command example.
> And we have to investigate the root cause of the issue and create a follow-up
> ticket to fix the way CLI parses the command line. I expect the example
> command to be valid.
> We have to provide user-friendly response in any case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20172) TX code cleanup scope #1 initial common cleanup
Anton Vinogradov created IGNITE-20172: - Summary: TX code cleanup scope #1 initial common cleanup Key: IGNITE-20172 URL: https://issues.apache.org/jira/browse/IGNITE-20172 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20171) 'Unknown error' in case of empty Problem JSON in error rest response
[
https://issues.apache.org/jira/browse/IGNITE-20171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Baranov updated IGNITE-20171:
Description:
If there is no Problem json in rest respone on some error, CLI interface shows
message like
{{Unknown error}}
{{argument "content" is null}}
The root cause of the issue it cli rest client. Rest client generated required
param validation like
// verify the required parameter 'roleName' is set
if (roleName == null) {
throw new ApiException("Missing the required parameter 'roleName' when calling
getPrivileges(Async)");
}
in this case client send 500 error without any content (by spec Problem content
should be)
it cause {{Unknown error }}in CLI console
was:
If there is no Problem json in rest respone on some error, CLI interface shows
message like
{{Unknown error}}
{{argument "content" is null}}
> 'Unknown error' in case of empty Problem JSON in error rest response
>
>
> Key: IGNITE-20171
> URL: https://issues.apache.org/jira/browse/IGNITE-20171
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Affects Versions: 3.0.0-beta1
>Reporter: Dmitry Baranov
>Assignee: Dmitry Baranov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If there is no Problem json in rest respone on some error, CLI interface
> shows message like
> {{Unknown error}}
> {{argument "content" is null}}
>
> The root cause of the issue it cli rest client. Rest client generated
> required param validation like
>
> // verify the required parameter 'roleName' is set
> if (roleName == null) {
> throw new ApiException("Missing the required parameter 'roleName' when
> calling getPrivileges(Async)");
> }
>
> in this case client send 500 error without any content (by spec Problem
> content should be)
> it cause {{Unknown error }}in CLI console
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19841) Java thin 3.0: Add tests to enforce consistent schema validation behavior across client and embedded APIs
[ https://issues.apache.org/jira/browse/IGNITE-19841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19841: Description: See *ItThinClientMarshallingTest* - verify all scenarios according to parent epic. * Insert tuple with columns A, B, C set - success * Insert tuple with columns A, B set - success (C takes default value) * Insert tuple with columns A, C set - exception (required column B not provided) * Insert tuple with columns A, B, D set - exception (column D is not mapped) * Alter table T drop column B; insert tuple with column A set - success (C takes default value) * Alter table T drop column B; insert tuple with columns A, B set - exception (column B is not mapped) * Alter table T add column D; insert tuple with columns A, B, C, D set - success * Alter table T add column D; insert tuple with columns A, B, C set - exception (required column D not provided) was:See *ItThinClientMarshallingTest* - verify all scenarios according to parent epic. > Java thin 3.0: Add tests to enforce consistent schema validation behavior > across client and embedded APIs > - > > Key: IGNITE-19841 > URL: https://issues.apache.org/jira/browse/IGNITE-19841 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See *ItThinClientMarshallingTest* - verify all scenarios according to parent > epic. > * Insert tuple with columns A, B, C set - success > * Insert tuple with columns A, B set - success (C takes default value) > * Insert tuple with columns A, C set - exception (required column B not > provided) > * Insert tuple with columns A, B, D set - exception (column D is not mapped) > * Alter table T drop column B; insert tuple with column A set - success (C > takes default value) > * Alter table T drop column B; insert tuple with columns A, B set - exception > (column B is not mapped) > * Alter table T add column D; insert tuple with columns A, B, C, D set - > success > * Alter table T add column D; insert tuple with columns A, B, C set - > exception (required column D not provided) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19895) Sql. QueryCancel#cancel cheat checking exception hierarchy
[
https://issues.apache.org/jira/browse/IGNITE-19895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19895:
Description:
Check code below (QueryCancel#cancel), casts checked exception into unchecked
one thus there are exist some places without catching such exception which can
lead to tx\resources leakage.
{code:java}
public synchronized void cancel() {
if (canceled) {
return;
}
canceled = true;
IgniteException ex = null;
// Run actions in the reverse order.
for (int i = cancelActions.size() - 1; i >= 0; i--) {
try {
Cancellable act = cancelActions.get(i);
act.cancel();
} catch (Exception e) {
if (ex == null) {
ex = new SqlException(CANCEL_OPERATION_ERR, e);
} else {
ex.addSuppressed(e);
}
}
}
if (ex != null) {
throw ex;
}
}
{code}
and call this method from : SqlQueryProcessor#querySingle0 like
stage.whenComplete((cur, ex) -> {
if (ex instanceof CancellationException) {
*queryCancel.cancel();*
}
if (ex != null && outerTx == null) {
InternalTransaction tx0 = tx.get();
if (tx0 != null) {
tx0.rollback();
}
}
}
may stay internal tx untouched, as i can see
was:
Check code below, casts checked exception into unchecked one thus there are
exist some places without catching such exception which can lead to
tx\resources leakage.
{code:java}
public synchronized void cancel() {
if (canceled) {
return;
}
canceled = true;
IgniteException ex = null;
// Run actions in the reverse order.
for (int i = cancelActions.size() - 1; i >= 0; i--) {
try {
Cancellable act = cancelActions.get(i);
act.cancel();
} catch (Exception e) {
if (ex == null) {
ex = new SqlException(CANCEL_OPERATION_ERR, e);
} else {
ex.addSuppressed(e);
}
}
}
if (ex != null) {
throw ex;
}
}
{code}
> Sql. QueryCancel#cancel cheat checking exception hierarchy
> --
>
> Key: IGNITE-19895
> URL: https://issues.apache.org/jira/browse/IGNITE-19895
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Check code below (QueryCancel#cancel), casts checked exception into unchecked
> one thus there are exist some places without catching such exception which
> can lead to tx\resources leakage.
> {code:java}
> public synchronized void cancel() {
> if (canceled) {
> return;
> }
> canceled = true;
> IgniteException ex = null;
> // Run actions in the reverse order.
> for (int i = cancelActions.size() - 1; i >= 0; i--) {
> try {
> Cancellable act = cancelActions.get(i);
> act.cancel();
> } catch (Exception e) {
> if (ex == null) {
> ex = new SqlException(CANCEL_OPERATION_ERR, e);
> } else {
> ex.addSuppressed(e);
> }
> }
> }
> if (ex != null) {
> throw ex;
> }
> }
> {code}
> and call this method from : SqlQueryProcessor#querySingle0 like
> stage.whenComplete((cur, ex) -> {
> if (ex instanceof CancellationException) {
> *queryCancel.cancel();*
> }
> if (ex != null && outerTx == null) {
> InternalTransaction tx0 = tx.get();
> if (tx0 != null) {
> tx0.rollback();
> }
> }
> }
> may stay internal tx untouched, as i can see
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19895) Sql. QueryCancel#cancel cheat checking exception hierarchy
[
https://issues.apache.org/jira/browse/IGNITE-19895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19895:
Description:
Check code below (QueryCancel#cancel), casts checked exception into unchecked
one thus there are exist some places without catching such exception which can
lead to tx\resources leakage.
{code:java}
public synchronized void cancel() {
if (canceled) {
return;
}
canceled = true;
IgniteException ex = null;
// Run actions in the reverse order.
for (int i = cancelActions.size() - 1; i >= 0; i--) {
try {
Cancellable act = cancelActions.get(i);
act.cancel();
} catch (Exception e) {
if (ex == null) {
ex = new SqlException(CANCEL_OPERATION_ERR, e);
} else {
ex.addSuppressed(e);
}
}
}
if (ex != null) {
throw ex;
}
}
{code}
and call this method from : SqlQueryProcessor#querySingle0 like
{noformat}
stage.whenComplete((cur, ex) -> {
if (ex instanceof CancellationException) {
*queryCancel.cancel();*
}
if (ex != null && outerTx == null) {
InternalTransaction tx0 = tx.get();
if (tx0 != null) {
tx0.rollback();
}
}
}
{noformat}
may stay internal tx untouched, as i can see
was:
Check code below (QueryCancel#cancel), casts checked exception into unchecked
one thus there are exist some places without catching such exception which can
lead to tx\resources leakage.
{code:java}
public synchronized void cancel() {
if (canceled) {
return;
}
canceled = true;
IgniteException ex = null;
// Run actions in the reverse order.
for (int i = cancelActions.size() - 1; i >= 0; i--) {
try {
Cancellable act = cancelActions.get(i);
act.cancel();
} catch (Exception e) {
if (ex == null) {
ex = new SqlException(CANCEL_OPERATION_ERR, e);
} else {
ex.addSuppressed(e);
}
}
}
if (ex != null) {
throw ex;
}
}
{code}
and call this method from : SqlQueryProcessor#querySingle0 like
stage.whenComplete((cur, ex) -> {
if (ex instanceof CancellationException) {
*queryCancel.cancel();*
}
if (ex != null && outerTx == null) {
InternalTransaction tx0 = tx.get();
if (tx0 != null) {
tx0.rollback();
}
}
}
may stay internal tx untouched, as i can see
> Sql. QueryCancel#cancel cheat checking exception hierarchy
> --
>
> Key: IGNITE-19895
> URL: https://issues.apache.org/jira/browse/IGNITE-19895
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Check code below (QueryCancel#cancel), casts checked exception into unchecked
> one thus there are exist some places without catching such exception which
> can lead to tx\resources leakage.
> {code:java}
> public synchronized void cancel() {
> if (canceled) {
> return;
> }
> canceled = true;
> IgniteException ex = null;
> // Run actions in the reverse order.
> for (int i = cancelActions.size() - 1; i >= 0; i--) {
> try {
> Cancellable act = cancelActions.get(i);
> act.cancel();
> } catch (Exception e) {
> if (ex == null) {
> ex = new SqlException(CANCEL_OPERATION_ERR, e);
> } else {
> ex.addSuppressed(e);
> }
> }
> }
> if (ex != null) {
> throw ex;
> }
> }
> {code}
> and call this method from : SqlQueryProcessor#querySingle0 like
> {noformat}
> stage.whenComplete((cur, ex) -> {
> if (ex instanceof CancellationException) {
> *queryCancel.cancel();*
> }
> if (ex != null && outerTx == null) {
> InternalTransaction tx0 = tx.get();
> if (tx0 != null) {
> tx0.rollback();
> }
> }
> }
> {noformat}
> may stay internal tx untouched, as i can see
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19841) Java thin 3.0: Add tests to enforce consistent schema validation behavior across client and embedded APIs
[ https://issues.apache.org/jira/browse/IGNITE-19841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19841: Description: See *ItThinClientMarshallingTest* - verify all scenarios according to parent epic. (was: See *ItThinClientMarshallingTest* - handle all scenarios according to parent epic.) > Java thin 3.0: Add tests to enforce consistent schema validation behavior > across client and embedded APIs > - > > Key: IGNITE-19841 > URL: https://issues.apache.org/jira/browse/IGNITE-19841 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See *ItThinClientMarshallingTest* - verify all scenarios according to parent > epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19841) Java thin 3.0: Add tests to enforce consistent schema validation behavior across client and embedded APIs
[ https://issues.apache.org/jira/browse/IGNITE-19841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19841: Description: See *ItThinClientMarshallingTest* - handle all scenarios according to parent epic. > Java thin 3.0: Add tests to enforce consistent schema validation behavior > across client and embedded APIs > - > > Key: IGNITE-19841 > URL: https://issues.apache.org/jira/browse/IGNITE-19841 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See *ItThinClientMarshallingTest* - handle all scenarios according to parent > epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20171) 'Unknown error' in case of empty Problem JSON in error rest response
Dmitry Baranov created IGNITE-20171:
---
Summary: 'Unknown error' in case of empty Problem JSON in error
rest response
Key: IGNITE-20171
URL: https://issues.apache.org/jira/browse/IGNITE-20171
Project: Ignite
Issue Type: Bug
Components: cli
Affects Versions: 3.0.0-beta1
Reporter: Dmitry Baranov
If there is no Problem json in rest respone on some error, CLI interface shows
message like
{{Unknown error}}
{{argument "content" is null}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20171) 'Unknown error' in case of empty Problem JSON in error rest response
[
https://issues.apache.org/jira/browse/IGNITE-20171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Baranov reassigned IGNITE-20171:
---
Assignee: Dmitry Baranov
> 'Unknown error' in case of empty Problem JSON in error rest response
>
>
> Key: IGNITE-20171
> URL: https://issues.apache.org/jira/browse/IGNITE-20171
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Affects Versions: 3.0.0-beta1
>Reporter: Dmitry Baranov
>Assignee: Dmitry Baranov
>Priority: Major
>
> If there is no Problem json in rest respone on some error, CLI interface
> shows message like
> {{Unknown error}}
> {{argument "content" is null}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20168) MultiActorPlacementDriverTest#testLeaseProlong is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20168:
--
Description:
TC run:
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7412161?hideProblemsFromDependencies=false=false+Inspection=true=true=true=true]
For some reason, lease was not created within timeout:
{code:java}
[07:38:49]F:
[org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong()]
org.opentest4j.AssertionFailedError: expected: but was:
[07:38:49]F:
[org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong()]
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at
app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.checkLeaseCreated(MultiActorPlacementDriverTest.java:571)
at
app//org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong(MultiActorPlacementDriverTest.java:368)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
at
app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
[jira] [Updated] (IGNITE-20168) MultiActorPlacementDriverTest#testLeaseProlong is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20168:
--
Attachment: test.log
> MultiActorPlacementDriverTest#testLeaseProlong is flaky
> ---
>
> Key: IGNITE-20168
> URL: https://issues.apache.org/jira/browse/IGNITE-20168
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Attachments: _Integration_Tests_Run_All_Other_13189.log.zip, test.log
>
>
> TC run:
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7412161?hideProblemsFromDependencies=false=false+Inspection=true=true=true=true]
> For some reason, lease was not created within timeout:
>
> {code:java}
> [07:38:49]F:
> [org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong()]
> org.opentest4j.AssertionFailedError: expected: but was:
>
> [07:38:49]F:
> [org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong()]
> org.opentest4j.AssertionFailedError: expected: but was:
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.checkLeaseCreated(MultiActorPlacementDriverTest.java:571)
> at
> app//org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong(MultiActorPlacementDriverTest.java:368)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
>
[jira] [Commented] (IGNITE-19839) Java thin 3.0: Reload schema when unmapped POJO column is detected
[ https://issues.apache.org/jira/browse/IGNITE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751568#comment-17751568 ] Pavel Tupitsyn commented on IGNITE-19839: - Merged to main: 28111df1a22fcf7a493a4e340dec3064726bce8d > Java thin 3.0: Reload schema when unmapped POJO column is detected > -- > > Key: IGNITE-19839 > URL: https://issues.apache.org/jira/browse/IGNITE-19839 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19839) Java thin 3.0: Reload schema when unmapped POJO column is detected
[ https://issues.apache.org/jira/browse/IGNITE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751558#comment-17751558 ] Igor Sapego commented on IGNITE-19839: -- Looks good to me. > Java thin 3.0: Reload schema when unmapped POJO column is detected > -- > > Key: IGNITE-19839 > URL: https://issues.apache.org/jira/browse/IGNITE-19839 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19361) Sql. UUID. Add removed test cases.
[
https://issues.apache.org/jira/browse/IGNITE-19361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-19361:
-
Assignee: Maksim Zhuravkov
> Sql. UUID. Add removed test cases.
> --
>
> Key: IGNITE-19361
> URL: https://issues.apache.org/jira/browse/IGNITE-19361
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
> Labels: ignite-3
>
> Add tests for invalid UUID values:
> {code:java}
> /** Invalid {@code UUID} string. */
> @Test
> public void testInvalidUuidString() {
> IgniteException t = assertThrows(IgniteException.class, () ->
> runSql("SELECT '00'::UUID"));
> assertThat(t.getMessage(), containsString("Invalid UUID string"));
> }
> /** Invalid {@code UUID} string in dynamic parameter. */
> @Test
> public void testInvalidUuidStringInDynamicParams() {
> IgniteException t = assertThrows(IgniteException.class, () ->
> runSql("SELECT ?::UUID", "0"));
> assertThat(t.getMessage(), containsString("Invalid UUID string"));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18426) Sql. Fix distribution function to use the distribution zone ID instead of the table ID.
[
https://issues.apache.org/jira/browse/IGNITE-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-18426:
--
Assignee: (was: Andrey Mashenkov)
> Sql. Fix distribution function to use the distribution zone ID instead of the
> table ID.
> ---
>
> Key: IGNITE-18426
> URL: https://issues.apache.org/jira/browse/IGNITE-18426
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The affinity function must be adjusted in IGNITE-18211, but it currently uses
> the table ID instead of the distribution zone ID because distribution zones
> do not have table integration.
> We need to fix this after IGNITE-18089.
> Not forget:
> * Enable ItSetOpTest#testSetOpColocated
> * Change the {{zoneId}} type from {{Object}} to actual type.
> * Fix other {{TODO}} related to IGNITE-18426.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18426) Sql. Fix distribution function to use the distribution zone ID instead of the table ID.
[
https://issues.apache.org/jira/browse/IGNITE-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18426:
---
Description:
The affinity function must be adjusted in IGNITE-18211, but it currently uses
the table ID instead of the distribution zone ID because distribution zones do
not have table integration.
We need to fix this after IGNITE-18089.
Not forget:
* Enable ItSetOpTest#testSetOpColocated
* Change the {{zoneId}} type from {{Object}} to actual type.
* Fix other {{TODO}} related to IGNITE-18426.
was:
The affinity function must be adjusted in IGNITE-18211, but it currently uses
the table ID instead of the distribution zone ID because distribution zones do
not have table integration.
We need to fix this after IGNITE-18089.
Not forget:
* Enable ItSetOpTest#testSetOpColocated
* Change the {{zoneId}} type from {{Object}} to actual type.
* Fix other {{TODO}} related to IGNITE-18426.
> Sql. Fix distribution function to use the distribution zone ID instead of the
> table ID.
> ---
>
> Key: IGNITE-18426
> URL: https://issues.apache.org/jira/browse/IGNITE-18426
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The affinity function must be adjusted in IGNITE-18211, but it currently uses
> the table ID instead of the distribution zone ID because distribution zones
> do not have table integration.
> We need to fix this after IGNITE-18089.
> Not forget:
> * Enable ItSetOpTest#testSetOpColocated
> * Change the {{zoneId}} type from {{Object}} to actual type.
> * Fix other {{TODO}} related to IGNITE-18426.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20149) Sql. Revise use INTERNAL_ERR in sql module
[ https://issues.apache.org/jira/browse/IGNITE-20149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20149: --- Epic Link: IGNITE-14611 > Sql. Revise use INTERNAL_ERR in sql module > -- > > Key: IGNITE-20149 > URL: https://issues.apache.org/jira/browse/IGNITE-20149 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Error code Common.INTERNAL_ERR should use only for internal error, which > could treat as a bug require attention from developer. However we use the > error code often and for normal situation, e.g. node left during execution of > a query. > Let's revise SQL module on use INTERNAL_ERR error code according the above. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20149) Sql. Revise use INTERNAL_ERR in sql module
[ https://issues.apache.org/jira/browse/IGNITE-20149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20149: --- Description: Error code Common.INTERNAL_ERR should use only for internal error, which could treat as a bug require attention from developer. However we use the error code often and for normal situation, e.g. node left during execution of a query. Let's revise SQL module on use INTERNAL_ERR error code according the above. was: Error code Common.INTERNAL_ERR should use only for internal error, which could treat as a bug require attention from developer. However we use the error code often and for normal situation, e.g. node left during execution of a query. Let's revise SQL module on use INTERNAL_ERR error code according the above. > Sql. Revise use INTERNAL_ERR in sql module > -- > > Key: IGNITE-20149 > URL: https://issues.apache.org/jira/browse/IGNITE-20149 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Error code Common.INTERNAL_ERR should use only for internal error, which > could treat as a bug require attention from developer. However we use the > error code often and for normal situation, e.g. node left during execution of > a query. > Let's revise SQL module on use INTERNAL_ERR error code according the above. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20161) Fix NPE in AppendEntriesRequestProcessor
[ https://issues.apache.org/jira/browse/IGNITE-20161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751508#comment-17751508 ] Roman Puchkovskiy commented on IGNITE-20161: It seems that this (and other) pools are nullified on join() because 2 tests in ItNodeTest (namely, the test that test bootstrap) are reusing NodeOptions objects: first such an object is used to bootstrap a node, then to init it. JRaft does not have NodeOptions inside BootstrapOptions at all; it seems that in our code it's added to share executors. But the intended way to share them is by using sharedPools = true which is not the case for the given tests. So it looks like the tests 'kinda share' the pools is another way deliberately. This looks weird and it's most likely not what was intended. That's the reason why I removed that 'sharing' in the 2 tests. This allows to remove the nullifying, which in turn makes the production code more robust (NPEs cannot happen anymore). > Fix NPE in AppendEntriesRequestProcessor > > > Key: IGNITE-20161 > URL: https://issues.apache.org/jira/browse/IGNITE-20161 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7408964?hideProblemsFromDependencies=false=false=true=true+Inspection=true > 2023-08-03 11:57:25:040 +0300 > [INFO][%int_tsdlttn_5005%JRaft-FSMCaller-Disruptor-_stripe_0-0][StateMachineAdapter] > onStartFollowing: LeaderChangeContext [leaderId=int_tsdlttn_5003, term=2, > status=Status[ENEWLEADER<10011>: Follower receives message from new leader > with the same term.]]. > 2023-08-03 11:57:25:040 +0300 > [ERROR][%int_tsdlttn_5004%MessagingService-inbound--0][DefaultMessagingService] > onMessage() failed while processing InvokeRequestImpl [correlationId=4, > message=AppendEntriesRequestImpl [committedIndex=0, > data=org.apache.ignite.raft.jraft.util.ByteString@1, entriesList=null, > groupId=unitest, peerId=int_tsdlttn_5004, prevLogIndex=1, prevLogTerm=1, > serverId=int_tsdlttn_5003, term=2, timestampLong=110824852359479296]] from > int_tsdlttn_5003 > java.lang.NullPointerException > at > org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor.getOrCreatePeerRequestContext(AppendEntriesRequestProcessor.java:351) > at > org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor$PeerExecutorSelector.select(AppendEntriesRequestProcessor.java:72) > at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.onReceived(IgniteRpcServer.java:182) > at > org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:375) > at > org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:335) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20170) Sql. AbstractPlannerTest#checkSplitAndSerialization founds serialization\deserialization problems.
Evgeny Stanilovsky created IGNITE-20170:
---
Summary: Sql. AbstractPlannerTest#checkSplitAndSerialization
founds serialization\deserialization problems.
Key: IGNITE-20170
URL: https://issues.apache.org/jira/browse/IGNITE-20170
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Check case below :
{noformat}
@Test
public void test0() throws Throwable {
sql("SELECT CAST('1'::TINYINT AS
FLOAT)").ok().getExecutable().execute();
}
{noformat}
serialization\deserialization check return:
{noformat}
Caused by: org.opentest4j.AssertionFailedError: Invalid serialization /
deserialization.
Expected:
rel#10:IgniteValues.(type=RecordType(FLOAT EXPR$0),tuples=[{ 1 }])
Deserialized:
rel#11:IgniteValues.(type=RecordType(FLOAT EXPR$0),tuples=[{ 1E0 }])
{noformat}
seems need to be fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20128) Sql. Clean up ignored SQL tests
[ https://issues.apache.org/jira/browse/IGNITE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20128: --- Labels: calcite2-required ignite-3 (was: ) > Sql. Clean up ignored SQL tests > --- > > Key: IGNITE-20128 > URL: https://issues.apache.org/jira/browse/IGNITE-20128 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: calcite2-required, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h > Remaining Estimate: 0h > > We have buch of muted, but works test, or muted tests which shouldn't work at > all. > Let's do our tests are a little bit less messed. > Test require attention: > sql/sqlite/join/join1.test_ignore > sql/sqlite/select2/select2_erroneous_hash_res.test_ignored > sql/sqlite/select2/select2_erroneous_res.test_ignored > sql/sqlite/select3/select3_erroneous_hash_res.test_ignore > sql/sqlite/select3/select3_erroneous_res.test_ignore > sql/subquery/table/test_aliasing.test_ignore > sql/filter/test_constant_comparisons.test_ignore > sql/insert/test_insert_type.test_ignore > sql/filter/test_obsolete_filters.test_ignore > sql/order/test_order_same_value.test_slow_ignore > sql/subquery/table/test_table_subquery.test_ignore > sql/subquery/any_all/test_uncorrelated_all_subquery.test_ignore > sql/subquery/any_all/test_uncorrelated_any_subquery.test_ignored > sql/subquery/scalar/test_uncorrelated_scalar_subquery.test_ignore > Tickets require attention: > https://issues.apache.org/jira/browse/IGNITE-14617 > https://issues.apache.org/jira/browse/IGNITE-15561 > https://issues.apache.org/jira/browse/IGNITE-15583 > https://issues.apache.org/jira/browse/IGNITE-15586 > https://issues.apache.org/jira/browse/IGNITE-15605 > https://issues.apache.org/jira/browse/IGNITE-17644 > https://issues.apache.org/jira/browse/IGNITE-17921 > https://issues.apache.org/jira/browse/IGNITE-18365 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15561) Calcite. Some kind of obsolete filters are failed.
[
https://issues.apache.org/jira/browse/IGNITE-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-15561.
Resolution: Won't Fix
Example from the ticket is incorrect due to WHERE should contains boolean
expression. No any numeric type could be implicitly cast to a boolean
> Calcite. Some kind of obsolete filters are failed.
> --
>
> Key: IGNITE-15561
> URL: https://issues.apache.org/jira/browse/IGNITE-15561
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> SqlRunner tests are failed.
> {noformat}
> query II
> SELECT * FROM integers WHERE 0
> SELECT * FROM integers WHERE a<2 AND 0
> {noformat}
> {noformat}
> /filter/test_obsolete_filters.test_ignore
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15583) Calcite. Column not found error with correlated sub query.
[
https://issues.apache.org/jira/browse/IGNITE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15583:
---
Labels: calcite calcite2-required (was: calcite calcite2-required
calcite3-required ignite-3)
> Calcite. Column not found error with correlated sub query.
> --
>
> Key: IGNITE-15583
> URL: https://issues.apache.org/jira/browse/IGNITE-15583
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required
>
> {noformat}
> statement ok
> CREATE TABLE integers(i INTEGER)
> statement ok
> INSERT INTO integers VALUES (1), (2), (3), (NULL)
> query IR
> SELECT (SELECT MAX(i) FROM integers) AS k, SUM(i) FROM integers GROUP BY k;
>
> 3 6.00
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 74:
> Column 'K' not found in any table
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> {noformat}
> {noformat}
> /subquery/any_all/test_uncorrelated_all_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14885) Calcite engine. Allow grouping by alias or ordinal
[
https://issues.apache.org/jira/browse/IGNITE-14885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-14885:
---
Labels: calcite2-required (was: calcite2-required calcite3-required)
> Calcite engine. Allow grouping by alias or ordinal
> --
>
> Key: IGNITE-14885
> URL: https://issues.apache.org/jira/browse/IGNITE-14885
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required
>
> Currently, grouping by alias or ordinal is not supported, but sometimes it
> can be handy.
> Some DB vendors support this feature (PostgreSQL, MySQL), but some not
> (Oracle, MSSQL). In the current Ignite H2-based SQL engine, this feature is
> not supported. We should decide do we need it in Ignite with calcite-based
> SQL engine.
> This feature can be easily enabled by redefining
> {{SqlConformance#isGroupByAlias}}, {{SqlConformance#isGroupByOrdinal}}
> Affected tests:
> {{src/test/sql/aggregate/group/test_group_by.test}}
> {{src/test/sql/aggregate/group/test_group_by_alias.test}}
> And many other.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17644) Some natural join syntax is erroneously reported as not valid [CALCITE-5253]
[ https://issues.apache.org/jira/browse/IGNITE-17644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-17644. Resolution: Cannot Reproduce > Some natural join syntax is erroneously reported as not valid [CALCITE-5253] > - > > Key: IGNITE-17644 > URL: https://issues.apache.org/jira/browse/IGNITE-17644 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > After upgrading to apache calcite 1.31 [1] some tests with natural join are > failed, would be fixed under [2], tests: /sql/sqlite/join/join1.test_ignore > [1] https://issues.apache.org/jira/browse/IGNITE-16040 > [2] https://issues.apache.org/jira/browse/CALCITE-5253 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18365) Sql. class java.lang.Integer cannot be cast to class java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-18365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-18365.
Resolution: Cannot Reproduce
> Sql. class java.lang.Integer cannot be cast to class java.lang.String
> -
>
> Key: IGNITE-18365
> URL: https://issues.apache.org/jira/browse/IGNITE-18365
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Actions leads to exception:
> {code:java}
> CREATE TABLE strings(a VARCHAR);
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (3), (4), (NULL);
> INSERT INTO strings SELECT * FROM integers;
> {code}
> {code:java}
> Caused by: java.lang.ClassCastException: class java.lang.Integer cannot be
> cast to class java.lang.String (java.lang.Integer and java.lang.String are in
> module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.schema.row.RowAssembler.writeValue(RowAssembler.java:228)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.updateTuple(IgniteTableImpl.java:421)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.toModifyRow(IgniteTableImpl.java:314)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-14617) Calcite. Add opportunity to use NUMERIC in WHEN syntax.
[
https://issues.apache.org/jira/browse/IGNITE-14617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-14617.
Resolution: Not A Problem
by SQL standard CASE WHEN could take just boolean expression, so example from
the ticket is incorrect
> Calcite. Add opportunity to use NUMERIC in WHEN syntax.
> ---
>
> Key: IGNITE-14617
> URL: https://issues.apache.org/jira/browse/IGNITE-14617
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite
>
> Probably we need to support such kind of expressions:
> {noformat}
> SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
> {noformat}
> _WHEN 1=1_ - works correctly in such case. Additional info was given in [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-14612
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14617) Calcite. Add opportunity to use NUMERIC in WHEN syntax.
[
https://issues.apache.org/jira/browse/IGNITE-14617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-14617:
---
Labels: calcite (was: calcite calcite2-required calcite3-required)
> Calcite. Add opportunity to use NUMERIC in WHEN syntax.
> ---
>
> Key: IGNITE-14617
> URL: https://issues.apache.org/jira/browse/IGNITE-14617
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite
>
> Probably we need to support such kind of expressions:
> {noformat}
> SELECT CASE WHEN 1 THEN 13 ELSE 12 END;
> {noformat}
> _WHEN 1=1_ - works correctly in such case. Additional info was given in [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-14612
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20128) Sql. Clean up ignored SQL tests
[ https://issues.apache.org/jira/browse/IGNITE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-20128: Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Clean up ignored SQL tests > --- > > Key: IGNITE-20128 > URL: https://issues.apache.org/jira/browse/IGNITE-20128 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Fix For: 3.0.0-beta2 > > Time Spent: 2h > Remaining Estimate: 0h > > We have buch of muted, but works test, or muted tests which shouldn't work at > all. > Let's do our tests are a little bit less messed. > Test require attention: > sql/sqlite/join/join1.test_ignore > sql/sqlite/select2/select2_erroneous_hash_res.test_ignored > sql/sqlite/select2/select2_erroneous_res.test_ignored > sql/sqlite/select3/select3_erroneous_hash_res.test_ignore > sql/sqlite/select3/select3_erroneous_res.test_ignore > sql/subquery/table/test_aliasing.test_ignore > sql/filter/test_constant_comparisons.test_ignore > sql/insert/test_insert_type.test_ignore > sql/filter/test_obsolete_filters.test_ignore > sql/order/test_order_same_value.test_slow_ignore > sql/subquery/table/test_table_subquery.test_ignore > sql/subquery/any_all/test_uncorrelated_all_subquery.test_ignore > sql/subquery/any_all/test_uncorrelated_any_subquery.test_ignored > sql/subquery/scalar/test_uncorrelated_scalar_subquery.test_ignore > Tickets require attention: > https://issues.apache.org/jira/browse/IGNITE-14617 > https://issues.apache.org/jira/browse/IGNITE-15561 > https://issues.apache.org/jira/browse/IGNITE-15583 > https://issues.apache.org/jira/browse/IGNITE-15586 > https://issues.apache.org/jira/browse/IGNITE-15605 > https://issues.apache.org/jira/browse/IGNITE-17644 > https://issues.apache.org/jira/browse/IGNITE-17921 > https://issues.apache.org/jira/browse/IGNITE-18365 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20128) Sql. Clean up ignored SQL tests
[ https://issues.apache.org/jira/browse/IGNITE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751492#comment-17751492 ] Evgeny Stanilovsky commented on IGNITE-20128: - [~jooger] thank you for contribution, merged to main > Sql. Clean up ignored SQL tests > --- > > Key: IGNITE-20128 > URL: https://issues.apache.org/jira/browse/IGNITE-20128 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > We have buch of muted, but works test, or muted tests which shouldn't work at > all. > Let's do our tests are a little bit less messed. > Test require attention: > sql/sqlite/join/join1.test_ignore > sql/sqlite/select2/select2_erroneous_hash_res.test_ignored > sql/sqlite/select2/select2_erroneous_res.test_ignored > sql/sqlite/select3/select3_erroneous_hash_res.test_ignore > sql/sqlite/select3/select3_erroneous_res.test_ignore > sql/subquery/table/test_aliasing.test_ignore > sql/filter/test_constant_comparisons.test_ignore > sql/insert/test_insert_type.test_ignore > sql/filter/test_obsolete_filters.test_ignore > sql/order/test_order_same_value.test_slow_ignore > sql/subquery/table/test_table_subquery.test_ignore > sql/subquery/any_all/test_uncorrelated_all_subquery.test_ignore > sql/subquery/any_all/test_uncorrelated_any_subquery.test_ignored > sql/subquery/scalar/test_uncorrelated_scalar_subquery.test_ignore > Tickets require attention: > https://issues.apache.org/jira/browse/IGNITE-14617 > https://issues.apache.org/jira/browse/IGNITE-15561 > https://issues.apache.org/jira/browse/IGNITE-15583 > https://issues.apache.org/jira/browse/IGNITE-15586 > https://issues.apache.org/jira/browse/IGNITE-15605 > https://issues.apache.org/jira/browse/IGNITE-17644 > https://issues.apache.org/jira/browse/IGNITE-17921 > https://issues.apache.org/jira/browse/IGNITE-18365 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19789) Sql. Introduce RowSchema for RowFactory
[
https://issues.apache.org/jira/browse/IGNITE-19789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19789:
--
Affects Version/s: 3.0.0-beta1
> Sql. Introduce RowSchema for RowFactory
> ---
>
> Key: IGNITE-19789
> URL: https://issues.apache.org/jira/browse/IGNITE-19789
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> There are three way to create
> {{{}org.apache.ignite.internal.sql.engine.exec.RowHandler.RowFactory{}}}:
> {code:java}
> RowFactory factory(IgniteTypeFactory typeFactory, RelDataType rowType);
> RowFactory factory(IgniteTypeFactory typeFactory, List
> fieldTypes);
> RowFactory factory(Type... types);
> {code}
> The first two create unnecessary dependency on {{calcite}} library, the last
> one doesn't provide required type's parameters, like decimal scale, for
> instance.
> Let's replace all three methods with a single {{{}RowFactory
> factory(RowSchema schema){}}}, where {{RowSchema}} is a class that should be
> introduced.
> h4. Implementation Notes
> Although {{org.apache.ignite.internal.schema.BinaryTupleSchemas}} might seem
> like a good candidate on the role of RowSchema, it doesn't have exhaustive
> type's support. Besides, introducing new type to binary tuple is much complex
> procedure since it will affect every module. Thus, it's better to implement
> distinct schema optimised for RowHandler|RowFactory use case.
> RowSchema should support complex/nested objects
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
