[jira] [Updated] (IGNITE-18518) Sorted index scan may return obsolete row versions
[ https://issues.apache.org/jira/browse/IGNITE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18518: --- Description: According to the MV store design, indexes must be filtered before returning data to user. For example, imagine that a row is deleted. This means that there's a tombstone. But, there's still an entry in indexes, for column values that the row used to have. These should not be visible to end user. was: According to the MV store design, indexes must be filtered before returning data to user. For example, imagine that a row is deleted. This means that there's a tombstone. But, there's still an entry in indexes, for column values that the row used to have. There should not be visible to end user. > Sorted index scan may return obsolete row versions > -- > > Key: IGNITE-18518 > URL: https://issues.apache.org/jira/browse/IGNITE-18518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > According to the MV store design, indexes must be filtered before returning > data to user. For example, imagine that a row is deleted. This means that > there's a tombstone. > But, there's still an entry in indexes, for column values that the row used > to have. These should not be visible to end user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18518) Sorted index scan may return obsolete row versions
[ https://issues.apache.org/jira/browse/IGNITE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18518: --- Epic Link: IGNITE-17766 (was: IGNITE-17304) > Sorted index scan may return obsolete row versions > -- > > Key: IGNITE-18518 > URL: https://issues.apache.org/jira/browse/IGNITE-18518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > According to the MV store design, indexes must be filtered before returning > data to user. For example, imagine that a row is deleted. This means that > there's a tombstone. > But, there's still an entry in indexes, for column values that the row used > to have. There should not be visible to end user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17950) Sql. Investigate way of reworking query cancellation flow
[ https://issues.apache.org/jira/browse/IGNITE-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-17950: --- Assignee: Evgeny Stanilovsky > Sql. Investigate way of reworking query cancellation flow > - > > Key: IGNITE-17950 > URL: https://issues.apache.org/jira/browse/IGNITE-17950 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > To prevent locks from being held indefinitely, we need to make sure that the > root fragment of the query is the last to cancel. > Let's investigate how to achieve the goal with rework the query cancellation > flow in order to meet this requirement. > As result we should have one or few tickets to implementation, potentially it > will required some documents with describe the current state and proposed > changes to have final state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18569) Sql. Some queries exceptionally executed if some rules are disabled.
[
https://issues.apache.org/jira/browse/IGNITE-18569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-18569:
---
Assignee: Evgeny Stanilovsky
> Sql. Some queries exceptionally executed if some rules are disabled.
>
>
> Key: IGNITE-18569
> URL: https://issues.apache.org/jira/browse/IGNITE-18569
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite3-required, ignite-3
>
> Found that if only one aggregate rule *HashAggregateConverterRule.COLOCATED*
> become available (in practice it can win by summary weights), we obtain
> exception, like :
> concrete this test can be found in */sqlite/aggregates/agg1.test*.
> There are also numerous faled tests if only one aggregate rule become enabled.
> {noformat}
> Error at: (agg1.test_slow:113). sql: SELECT DISTINCT + 30 AS col0 FROM tab0,
> tab1 AS cor0
> Caused by: java.lang.IllegalStateException
> at
> org.apache.ignite.internal.sql.engine.trait.DistributionFunction$SingletonDistribution.destination(DistributionFunction.java:205)
> at
> org.apache.ignite.internal.sql.engine.trait.DistributionTrait.destination(DistributionTrait.java:109)
> at
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:161)
> {noformat}
> {noformat}
> //HashAggregateConverterRule.COLOCATED,
> HashAggregateConverterRule.MAP_REDUCE,
> //SortAggregateConverterRule.COLOCATED,
> //SortAggregateConverterRule.MAP_REDUCE,
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18559) Sql. The least restrictive type between VARCHAR and DECIMAL is DECIMAL(precision=32767, scale=16383)
[
https://issues.apache.org/jira/browse/IGNITE-18559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18559:
--
Description:
At the moment the least restrictive type between VARCHAR and DECIMAL is
DECIMAL(precision=32767, scale=16383). See TypeCoercionTest
testVarCharToNumeric.
Investigate why that happens and whether it is a problem or not.
Test query:
{code:java}
SELECT NULLIF(12.2, 'b') -- Should fail since types do not match {code}
was:
At the moment least restrictive type between VARCHAR and DECIMAL is
DECIMAL(precision=32767, scale=16383). See TypeCoercionTest
testVarCharToNumeric.
Investigate why that happens and whether it is a problem or not.
Test query:
{code:java}
SELECT NULLIF(12.2, 'b') -- Should fail since types do not match {code}
> Sql. The least restrictive type between VARCHAR and DECIMAL is
> DECIMAL(precision=32767, scale=16383)
>
>
> Key: IGNITE-18559
> URL: https://issues.apache.org/jira/browse/IGNITE-18559
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> At the moment the least restrictive type between VARCHAR and DECIMAL is
> DECIMAL(precision=32767, scale=16383). See TypeCoercionTest
> testVarCharToNumeric.
> Investigate why that happens and whether it is a problem or not.
> Test query:
> {code:java}
> SELECT NULLIF(12.2, 'b') -- Should fail since types do not match {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18676) [ducktests] Support --performance-statistics in the ControlUtility
Sergey Korotkov created IGNITE-18676: Summary: [ducktests] Support --performance-statistics in the ControlUtility Key: IGNITE-18676 URL: https://issues.apache.org/jira/browse/IGNITE-18676 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Add ability to run --performance-statistics [1] subcommands in ducktests via the ControlUtility class. [1] - the https://ignite.apache.org/docs/latest/monitoring-metrics/performance-statistics -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18675) cleanup map on cache group destroy implemented
Denis Kuznetsov created IGNITE-18675: Summary: cleanup map on cache group destroy implemented Key: IGNITE-18675 URL: https://issues.apache.org/jira/browse/IGNITE-18675 Project: Ignite Issue Type: Bug Reporter: Denis Kuznetsov Assignee: Denis Kuznetsov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17991) Thin 3.0: Incorrect colocation hash due to ignored precision for LocalTime, LocalDateTime, Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-17991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17991: Ignite Flags: (was: Docs Required,Release Notes Required) > Thin 3.0: Incorrect colocation hash due to ignored precision for LocalTime, > LocalDateTime, Timestamp > > > Key: IGNITE-17991 > URL: https://issues.apache.org/jira/browse/IGNITE-17991 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > RowAssembler serializes *LocalTime*, *LocalDateTime* and *Timestamp* > according to their *TemporalNativeType.precision*. This affects colocation > hash. > Client implementation ignores *precision* when calculating colocation hash, > resulting in different values when precision is less than maximum. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17992) .NET: Thin 3.0: Incorrect colocation hash due to ignored precision for LocalTime, LocalDateTime, Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682246#comment-17682246 ] Pavel Tupitsyn commented on IGNITE-17992: - Merged to main: 08171cc1a5078cb22bd87dee76c4774f79d2981b > .NET: Thin 3.0: Incorrect colocation hash due to ignored precision for > LocalTime, LocalDateTime, Timestamp > -- > > Key: IGNITE-17992 > URL: https://issues.apache.org/jira/browse/IGNITE-17992 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > RowAssembler serializes *LocalTime*, *LocalDateTime* and *Timestamp* > according to their *TemporalNativeType.precision*. This affects colocation > hash. > Client implementation ignores *precision* when calculating colocation hash, > resulting in different values when precision is less than maximum. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18674) Introduce UI thread to CLI
[ https://issues.apache.org/jira/browse/IGNITE-18674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-18674: --- Description: The current SQL query completion process may obstruct the UI thread and result in CLI hang-ups when Ignite 3 node fails to respond. To prevent this issue, we need to implement a separate UI thread for all user-facing operations with a maximum block time of 5-10 seconds. The CLI must be protected from indefinite hang-ups at all times, regardless of Ignite 3 node behavior. To accomplish this, we should adopt a single UI thread and worker pool design with asynchronous communication, allowing the UI thread to receive notifications without being blocked. was:Here is the context. > Introduce UI thread to CLI > -- > > Key: IGNITE-18674 > URL: https://issues.apache.org/jira/browse/IGNITE-18674 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > The current SQL query completion process may obstruct the UI thread and > result in CLI hang-ups when Ignite 3 node fails to respond. > To prevent this issue, we need to implement a separate UI thread for all > user-facing operations with a maximum block time of 5-10 seconds. The CLI > must be protected from indefinite hang-ups at all times, regardless of Ignite > 3 node behavior. To accomplish this, we should adopt a single UI thread and > worker pool design with asynchronous communication, allowing the UI thread to > receive notifications without being blocked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18674) Introduce UI thread to CLI
[ https://issues.apache.org/jira/browse/IGNITE-18674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-18674: --- Description: Here is the context. (was: Here is the context. Steps: download gridgain9-9.0.0-alpha1.zip from the Google Drive (see the link above) start a node with clean PDS via gridgain9-db-9.0.0-alpha1/bin/ignite3db start the CLI via gridgain9-cli-9.0.0-alpha1/bin/ignite3 init the cluster via CLI: cluster init --cluster-name gg9 --meta-storage-node defaultNode CLI: enter the sql mode via sql command create a table: CREATE TABLE person (id INT PRIMARY KEY, name VARCHAR) enable columnar storage: ALTER TABLE person ADD REPLICA ENGINE columnar insert a row: INSERT INTO person VALUES (1, 'name1') quit the CLI stop the node and start it back via the same ignite3db script start the CLI and enter the sql mode try to enter a SQL query) > Introduce UI thread to CLI > -- > > Key: IGNITE-18674 > URL: https://issues.apache.org/jira/browse/IGNITE-18674 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Here is the context. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18674) Introduce UI thread to CLI
Aleksandr created IGNITE-18674: -- Summary: Introduce UI thread to CLI Key: IGNITE-18674 URL: https://issues.apache.org/jira/browse/IGNITE-18674 Project: Ignite Issue Type: Task Components: cli Reporter: Aleksandr Here is the context. Steps: download gridgain9-9.0.0-alpha1.zip from the Google Drive (see the link above) start a node with clean PDS via gridgain9-db-9.0.0-alpha1/bin/ignite3db start the CLI via gridgain9-cli-9.0.0-alpha1/bin/ignite3 init the cluster via CLI: cluster init --cluster-name gg9 --meta-storage-node defaultNode CLI: enter the sql mode via sql command create a table: CREATE TABLE person (id INT PRIMARY KEY, name VARCHAR) enable columnar storage: ALTER TABLE person ADD REPLICA ENGINE columnar insert a row: INSERT INTO person VALUES (1, 'name1') quit the CLI stop the node and start it back via the same ignite3db script start the CLI and enter the sql mode try to enter a SQL query -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16196) Supports index rename
[ https://issues.apache.org/jira/browse/IGNITE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-16196: Priority: Minor (was: Major) > Supports index rename > - > > Key: IGNITE-16196 > URL: https://issues.apache.org/jira/browse/IGNITE-16196 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha3 >Reporter: Taras Ledkov >Priority: Minor > Labels: ignite-3 > > Need to supports index rename. > ALTER INDEX [ IF EXISTS ] RENAME TO -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17992) .NET: Thin 3.0: Incorrect colocation hash due to ignored precision for LocalTime, LocalDateTime, Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17992: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Thin 3.0: Incorrect colocation hash due to ignored precision for > LocalTime, LocalDateTime, Timestamp > -- > > Key: IGNITE-17992 > URL: https://issues.apache.org/jira/browse/IGNITE-17992 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > RowAssembler serializes *LocalTime*, *LocalDateTime* and *Timestamp* > according to their *TemporalNativeType.precision*. This affects colocation > hash. > Client implementation ignores *precision* when calculating colocation hash, > resulting in different values when precision is less than maximum. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means
that all user task execution requests received through REST or Thin client
protocols MUST be executed through PUBLIC API).
3. Add the ability to explicitly specify for SYSTEM
task/callable/runnable/closure what permission should be checked before its
execution. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories -
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
tasks (tasks that are part oof the ignite code but are available to the user
and can be executed through the PUBLIC API)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them are executed through Thin Client which is considered Public API.
Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
we must force the developer to explicitly specify permissions for tasks of this
type. It can be done by checking that SYSTEM tasks that are executed through
PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|auth by task name|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by specified permissions|auth skipped|
5. Authorization of SYSTEM tasks cancellation must be skipped it they are
canceled by the same user who started them, oterwise dedicated permissions is
required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
Possible troubles:
1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox
[jira] [Updated] (IGNITE-16785) Add configuration for the timeout for removing nodes from logical topology
[ https://issues.apache.org/jira/browse/IGNITE-16785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-16785: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Add configuration for the timeout for removing nodes from logical topology > -- > > Key: IGNITE-16785 > URL: https://issues.apache.org/jira/browse/IGNITE-16785 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h > Remaining Estimate: 0h > > When a node leaves the physical topology, it should be removed from the > logical topology after a timeout. This timeout should be configurable through > the configuration framework. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16785) Add configuration for the timeout for removing nodes from logical topology
[ https://issues.apache.org/jira/browse/IGNITE-16785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-16785: --- Ignite Flags: (was: Release Notes Required) > Add configuration for the timeout for removing nodes from logical topology > -- > > Key: IGNITE-16785 > URL: https://issues.apache.org/jira/browse/IGNITE-16785 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h > Remaining Estimate: 0h > > When a node leaves the physical topology, it should be removed from the > logical topology after a timeout. This timeout should be configurable through > the configuration framework. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means
that all user task execution requests received through REST or Thin client
protocols MUST be executed through PUBLIC API).
3. Add the ability to explicitly specify for SYSTEM
task/callable/runnable/closure what permission should be checked before its
execution. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories -
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
tasks (tasks that are part oof the ignite code but are available to the user
and can be executed through the PUBLIC API)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them are executed through Thin Client which is considered Public API.
Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
we must force the developer to explicitly specify permissions for tasks of this
type. It can be done by checking that SYSTEM tasks that are executed through
PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|auth by task name|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by specified permissions|auth by specified permissions|
5. Authorization of SYSTEM tasks cancellation must be skipped it they are
canceled by the same user who started them, oterwise dedicated permissions is
required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
Possible troubles:
1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in
[jira] [Assigned] (IGNITE-17958) PartitionListener should not close partition storage
[
https://issues.apache.org/jira/browse/IGNITE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-17958:
Assignee: Kirill Tkalenko
> PartitionListener should not close partition storage
>
>
> Key: IGNITE-17958
> URL: https://issues.apache.org/jira/browse/IGNITE-17958
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, {{PartitionListener}} closes partition storage when the listener
> is shut down. Probably the listener should not do such a thing because the
> storage was not created by it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Negative column indexes in ORDER BY clause are not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Description:
The simple example:
{code:java}
SELECT * FROM test ORDER BY -1
{code}
See test_order_by_exceptions.test.
Add statement error: to other test cases as well.
was:
The simple example:
{code:java}
SELECT * FROM test ORDER BY -1
{code}
> Sql. Negative column indexes in ORDER BY clause are not rejected
>
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The simple example:
> {code:java}
> SELECT * FROM test ORDER BY -1
> {code}
> See test_order_by_exceptions.test.
> Add statement error: to other test cases as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Negative column indexes in ORDER BY clause are not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Description:
The first query fails:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
{code}
Error:
{code:java}
>From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
{code}
But the second gets executed:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
{code}
An error message produced by the first query gives us a clue that the ORDER BY
clause is not checked at all.
The simple example:
{code:java}
SELECT * FROM test ORDER BY -1
{code}
was:
The first query fails:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
{code}
Error:
{code:java}
>From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
{code}
But the second gets executed:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
{code}
An error message produced by the first query gives us a clue that the ORDER BY
clause is not checked at all.
> Sql. Negative column indexes in ORDER BY clause are not rejected
>
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The first query fails:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
> {code}
> Error:
> {code:java}
> From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
> {code}
> But the second gets executed:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
> {code}
> An error message produced by the first query gives us a clue that the ORDER
> BY clause is not checked at all.
> The simple example:
> {code:java}
> SELECT * FROM test ORDER BY -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18335) Update Ignite dependency: Ant
[ https://issues.apache.org/jira/browse/IGNITE-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-18335: --- Description: Update Ignite dependency: Ant 1.8.2 to 1.10.13 was:Update Ignite dependency: Ant 1.8.2 to 1.10.12 > Update Ignite dependency: Ant > - > > Key: IGNITE-18335 > URL: https://issues.apache.org/jira/browse/IGNITE-18335 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency: Ant 1.8.2 to 1.10.13 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18335) Update Ignite dependency: Ant
[ https://issues.apache.org/jira/browse/IGNITE-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-18335: --- Release Note: Update Ignite dependency: Ant 1.8.2 to 1.10.13 was:Update Ignite dependency: Ant 1.8.2 to 1.10.12 > Update Ignite dependency: Ant > - > > Key: IGNITE-18335 > URL: https://issues.apache.org/jira/browse/IGNITE-18335 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency: Ant 1.8.2 to 1.10.13 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Negative column indexes in ORDER BY clause are not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Description:
The simple example:
{code:java}
SELECT * FROM test ORDER BY -1
{code}
was:
The first query fails:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
{code}
Error:
{code:java}
>From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
{code}
But the second gets executed:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
{code}
An error message produced by the first query gives us a clue that the ORDER BY
clause is not checked at all.
The simple example:
{code:java}
SELECT * FROM test ORDER BY -1
{code}
> Sql. Negative column indexes in ORDER BY clause are not rejected
>
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The simple example:
> {code:java}
> SELECT * FROM test ORDER BY -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Negative column indexes in ORDER BY clause are not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Summary: Sql. Negative column indexes in ORDER BY clause are not rejected
(was: Sql. Set operations. Invalid column index in ORDER BY sometimes is not
rejected)
> Sql. Negative column indexes in ORDER BY clause are not rejected
>
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The first query fails:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
> {code}
> Error:
> {code:java}
> From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
> {code}
> But the second gets executed:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
> {code}
> An error message produced by the first query gives us a clue that the ORDER
> BY clause is not checked at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18673) Sql. Set operations. Invalid column index in ORDER BY sometimes is not rejected
Maksim Zhuravkov created IGNITE-18673:
-
Summary: Sql. Set operations. Invalid column index in ORDER BY
sometimes is not rejected
Key: IGNITE-18673
URL: https://issues.apache.org/jira/browse/IGNITE-18673
Project: Ignite
Issue Type: Bug
Reporter: Maksim Zhuravkov
The first query fails:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
{code}
Error:
{code:java}
>From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
{code}
But the second gets executed:
{code:java}
SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
{code}
An error message produced by the first query gives us a clue that the ORDER BY
clause is not checked at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Set operations. Invalid column index in ORDER BY sometimes is not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Fix Version/s: 3.0.0-beta2
> Sql. Set operations. Invalid column index in ORDER BY sometimes is not
> rejected
> ---
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> The first query fails:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
> {code}
> Error:
> {code:java}
> From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
> {code}
> But the second gets executed:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
> {code}
> An error message produced by the first query gives us a clue that the ORDER
> BY clause is not checked at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Set operations. Invalid column index in ORDER BY sometimes is not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Component/s: sql
> Sql. Set operations. Invalid column index in ORDER BY sometimes is not
> rejected
> ---
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> The first query fails:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
> {code}
> Error:
> {code:java}
> From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
> {code}
> But the second gets executed:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
> {code}
> An error message produced by the first query gives us a clue that the ORDER
> BY clause is not checked at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18673) Sql. Set operations. Invalid column index in ORDER BY sometimes is not rejected
[
https://issues.apache.org/jira/browse/IGNITE-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18673:
--
Labels: calcite2-required calcite3-required ignite-3 (was: )
> Sql. Set operations. Invalid column index in ORDER BY sometimes is not
> rejected
> ---
>
> Key: IGNITE-18673
> URL: https://issues.apache.org/jira/browse/IGNITE-18673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The first query fails:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k FROM test ORDER BY -1
> {code}
> Error:
> {code:java}
> From line 1, column 40 to line 1, column 49: Column count mismatch in UNION
> {code}
> But the second gets executed:
> {code:java}
> SELECT a % 2, b FROM test UNION SELECT a % 2 AS k, b FROM test ORDER BY -1
> {code}
> An error message produced by the first query gives us a clue that the ORDER
> BY clause is not checked at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18672) Sql. cast(ASIN(n)*1000 as bigint) FROM numbers ORDER BY n is expected to fail
Maksim Zhuravkov created IGNITE-18672:
-
Summary: Sql. cast(ASIN(n)*1000 as bigint) FROM numbers ORDER BY n
is expected to fail
Key: IGNITE-18672
URL: https://issues.apache.org/jira/browse/IGNITE-18672
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Query was marked as expected to fail
{code:java}
SELECT cast(ASIN(n)*1000 as bigint) FROM numbers ORDER BY n
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18671) Sql. Cast to BigInt with overflow does not produce an error.
Maksim Zhuravkov created IGNITE-18671:
-
Summary: Sql. Cast to BigInt with overflow does not produce an
error.
Key: IGNITE-18671
URL: https://issues.apache.org/jira/browse/IGNITE-18671
Project: Ignite
Issue Type: Bug
Components: sql
Environment: See test_sum.test
Query
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
{code:java}
CREATE TABLE bigints(b BIGINT);
# a bunch of huge values
statement ok
INSERT INTO bigints SELECT * FROM table(system_range(4611686018427387904,
4611686018427388903, 1));
# this is too big for a bigint.
# should fail but returns the result below
query I
SELECT SUM(b)::BIGINT FROM bigints
499500
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18670) Sql. It is possible to reference aliases in GROUP BY clause.
Maksim Zhuravkov created IGNITE-18670:
-
Summary: Sql. It is possible to reference aliases in GROUP BY
clause.
Key: IGNITE-18670
URL: https://issues.apache.org/jira/browse/IGNITE-18670
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following query is considered invalid by some SQL frontends since they
decided that it is not legal to reference aliases in GROUP BY clause.
We should decide whether to reject such query or not as of now it works.
{code:java}
SELECT 1 AS k, SUM(i) FROM integers GROUP BY k+1 ORDER BY 2;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18669) Sql. from_base64 does not return errors for some invalid inputs
Maksim Zhuravkov created IGNITE-18669:
-
Summary: Sql. from_base64 does not return errors for some invalid
inputs
Key: IGNITE-18669
URL: https://issues.apache.org/jira/browse/IGNITE-18669
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Examples:
{code:java}
SELECT from_base64('ab');
SELECT from_base64('üab');
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18160) Delete physical data after a Raft Group is stopped
[
https://issues.apache.org/jira/browse/IGNITE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-18160:
Assignee: Kirill Tkalenko
> Delete physical data after a Raft Group is stopped
> --
>
> Key: IGNITE-18160
> URL: https://issues.apache.org/jira/browse/IGNITE-18160
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After a Raft Group is stopped on a node as a consequence of partition
> reassignment, we need to remove the partition data and the corresponding Raft
> log. This implies that for every storage a {{destroy}} method should be
> implemented with the following behaviour: it should return control to the
> caller as soon as possible, i.e. be asynchronous. Ideally this method should
> perform some minimal actions to pose failover guarantees and not wait for the
> data to be removed.
> We need to check that every storage type supports this method and add
> corresponding tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18160) Delete physical data after a Raft Group is stopped
[
https://issues.apache.org/jira/browse/IGNITE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-18160:
-
Fix Version/s: 3.0.0-beta2
> Delete physical data after a Raft Group is stopped
> --
>
> Key: IGNITE-18160
> URL: https://issues.apache.org/jira/browse/IGNITE-18160
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After a Raft Group is stopped on a node as a consequence of partition
> reassignment, we need to remove the partition data and the corresponding Raft
> log. This implies that for every storage a {{destroy}} method should be
> implemented with the following behaviour: it should return control to the
> caller as soon as possible, i.e. be asynchronous. Ideally this method should
> perform some minimal actions to pose failover guarantees and not wait for the
> data to be removed.
> We need to check that every storage type supports this method and add
> corresponding tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18160) Delete physical data after a Raft Group is stopped
[
https://issues.apache.org/jira/browse/IGNITE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-18160:
-
Epic Link: IGNITE-17774
> Delete physical data after a Raft Group is stopped
> --
>
> Key: IGNITE-18160
> URL: https://issues.apache.org/jira/browse/IGNITE-18160
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After a Raft Group is stopped on a node as a consequence of partition
> reassignment, we need to remove the partition data and the corresponding Raft
> log. This implies that for every storage a {{destroy}} method should be
> implemented with the following behaviour: it should return control to the
> caller as soon as possible, i.e. be asynchronous. Ideally this method should
> perform some minimal actions to pose failover guarantees and not wait for the
> data to be removed.
> We need to check that every storage type supports this method and add
> corresponding tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18668) Sql. Natural join as crossjoin
Maksim Zhuravkov created IGNITE-18668:
-
Summary: Sql. Natural join as crossjoin
Key: IGNITE-18668
URL: https://issues.apache.org/jira/browse/IGNITE-18668
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
When there no matching columns present natural join behaves like a cross join.
{code:java}
query I
select * from (values (1)) tbl(a) natural join (values (1), (2)) tbl2(b) order
by 1, 2
1 1
1 2
{code}
See natural_join.test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18667) sql. left outer join with correlated subquery fails
[
https://issues.apache.org/jira/browse/IGNITE-18667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18667:
--
Labels: calcite2-required calcite3-required ignite-3 (was: )
> sql. left outer join with correlated subquery fails
> ---
>
> Key: IGNITE-18667
> URL: https://issues.apache.org/jira/browse/IGNITE-18667
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following queries must work but the fail:
> {code:java}
> # left outer join on arbitrary correlated subquery
> statement ok
> SELECT * FROM integers s1 LEFT OUTER JOIN integers s2 ON (SELECT CASE WHEN
> s1.i+s2.i>10 THEN TRUE ELSE FALSE END) ORDER BY s1.i;
> {code}
> Expected:
> {code:java}
> i i
> 1 null
> 2 null
> 3 null
> null null
> {code}
> Actual:
> {code:java}
> Caused by: java.lang.AssertionError: All correlation variables should resolve
> to the same namespace. Prev
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@7f74c84c, new
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@11b2d99c
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:3006)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2916)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4865)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4930)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3253)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3173)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2392)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2280)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:694)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:675)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3737)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlToRelConvertor.convertQueryRecursive(IgniteSqlToRelConvertor.java:68)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:595)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18667) sql. left outer join with correlated subquery fails
[
https://issues.apache.org/jira/browse/IGNITE-18667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18667:
--
Fix Version/s: 3.0.0-beta2
> sql. left outer join with correlated subquery fails
> ---
>
> Key: IGNITE-18667
> URL: https://issues.apache.org/jira/browse/IGNITE-18667
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> The following queries must work but the fail:
> {code:java}
> # left outer join on arbitrary correlated subquery
> statement ok
> SELECT * FROM integers s1 LEFT OUTER JOIN integers s2 ON (SELECT CASE WHEN
> s1.i+s2.i>10 THEN TRUE ELSE FALSE END) ORDER BY s1.i;
> {code}
> Expected:
> {code:java}
> i i
> 1 null
> 2 null
> 3 null
> null null
> {code}
> Actual:
> {code:java}
> Caused by: java.lang.AssertionError: All correlation variables should resolve
> to the same namespace. Prev
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@7f74c84c, new
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@11b2d99c
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:3006)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2916)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4865)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4930)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3253)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3173)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2392)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2280)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:694)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:675)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3737)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlToRelConvertor.convertQueryRecursive(IgniteSqlToRelConvertor.java:68)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:595)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18667) sql. left outer join with correlated subquery fails
[
https://issues.apache.org/jira/browse/IGNITE-18667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18667:
--
Component/s: sql
> sql. left outer join with correlated subquery fails
> ---
>
> Key: IGNITE-18667
> URL: https://issues.apache.org/jira/browse/IGNITE-18667
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> The following queries must work but the fail:
> {code:java}
> # left outer join on arbitrary correlated subquery
> statement ok
> SELECT * FROM integers s1 LEFT OUTER JOIN integers s2 ON (SELECT CASE WHEN
> s1.i+s2.i>10 THEN TRUE ELSE FALSE END) ORDER BY s1.i;
> {code}
> Expected:
> {code:java}
> i i
> 1 null
> 2 null
> 3 null
> null null
> {code}
> Actual:
> {code:java}
> Caused by: java.lang.AssertionError: All correlation variables should resolve
> to the same namespace. Prev
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@7f74c84c, new
> ns=org.apache.calcite.sql.validate.IdentifierNamespace@11b2d99c
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:3006)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2916)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4865)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4930)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3253)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3173)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2392)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2280)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:694)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:675)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3737)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlToRelConvertor.convertQueryRecursive(IgniteSqlToRelConvertor.java:68)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:595)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18667) sql. left outer join with correlated subquery fails
Maksim Zhuravkov created IGNITE-18667:
-
Summary: sql. left outer join with correlated subquery fails
Key: IGNITE-18667
URL: https://issues.apache.org/jira/browse/IGNITE-18667
Project: Ignite
Issue Type: Bug
Reporter: Maksim Zhuravkov
The following queries must work but the fail:
{code:java}
# left outer join on arbitrary correlated subquery
statement ok
SELECT * FROM integers s1 LEFT OUTER JOIN integers s2 ON (SELECT CASE WHEN
s1.i+s2.i>10 THEN TRUE ELSE FALSE END) ORDER BY s1.i;
{code}
Expected:
{code:java}
i i
1 null
2 null
3 null
nullnull
{code}
Actual:
{code:java}
Caused by: java.lang.AssertionError: All correlation variables should resolve
to the same namespace. Prev
ns=org.apache.calcite.sql.validate.IdentifierNamespace@7f74c84c, new
ns=org.apache.calcite.sql.validate.IdentifierNamespace@11b2d99c
at
org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:3006)
at
org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2916)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4865)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4930)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3253)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3173)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2392)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2280)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:694)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:675)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3737)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlToRelConvertor.convertQueryRecursive(IgniteSqlToRelConvertor.java:68)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:595)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18666) Sql. Subqueries with invalid aggregates in subqueries are not rejected
Maksim Zhuravkov created IGNITE-18666:
-
Summary: Sql. Subqueries with invalid aggregates in subqueries are
not rejected
Key: IGNITE-18666
URL: https://issues.apache.org/jira/browse/IGNITE-18666
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following queries are expected to fail but they return some results:
{code:java}
# this will fail, because "i" is not an aggregate but the SUM(i1.i) turns this
query into an aggregate
skipif ignite3
statement error
SELECT i, (SELECT SUM(i1.i)) FROM integers i1;
# PG: ERROR: column "i1.i" must appear in the GROUP BY clause or be used in an
aggregate function
skipif ignite3
statement error
SELECT i+1, (SELECT SUM(i1.i)) FROM integers i1;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18665) Sql. subquery with ORDER BY is not supported
Maksim Zhuravkov created IGNITE-18665:
-
Summary: Sql. subquery with ORDER BY is not supported
Key: IGNITE-18665
URL: https://issues.apache.org/jira/browse/IGNITE-18665
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following query is not supported:
{code:java}
SELECT i, (WITH i2 AS (SELECT i+i1.i FROM integers ORDER BY 1 LIMIT 1 OFFSET 1)
SELECT * FROM i2) AS j FROM integers i1 ORDER BY i;
{code}
{code:java}
i j
1 3
2 4
3 5
nullnull
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18664) Sql. subquery with OFFSET is not supported
[
https://issues.apache.org/jira/browse/IGNITE-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18664:
--
Description:
The following query is not supported
{code:java}
SELECT i, (WITH i2 AS (SELECT i+i1.i FROM integers LIMIT 1 OFFSET 1) SELECT *
FROM i2) AS j FROM integers i1 ORDER BY i;
{code}
Expected result:
{code:java}
i j
1 3
2 4
3 5
nullnull
{code}
> Sql. subquery with OFFSET is not supported
> --
>
> Key: IGNITE-18664
> URL: https://issues.apache.org/jira/browse/IGNITE-18664
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query is not supported
> {code:java}
> SELECT i, (WITH i2 AS (SELECT i+i1.i FROM integers LIMIT 1 OFFSET 1) SELECT *
> FROM i2) AS j FROM integers i1 ORDER BY i;
> {code}
> Expected result:
> {code:java}
> i j
> 1 3
> 2 4
> 3 5
> null null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18663) Sql. DATE Literals are not validated correctly.
[
https://issues.apache.org/jira/browse/IGNITE-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18663:
--
Fix Version/s: 3.0.0-beta2
> Sql. DATE Literals are not validated correctly.
> ---
>
> Key: IGNITE-18663
> URL: https://issues.apache.org/jira/browse/IGNITE-18663
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Date literal with incorrect are not rejected. Some examples:
> {code:java}
> # month out of range
> INSERT INTO dates VALUES ('1993-20-14')
> # day out of range
> INSERT INTO dates VALUES ('1993-08-99')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1993-02-29')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1900-02-29')
> {code}
> See more examples in test_incorrect_dates.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18664) Sql. subquery with OFFSET is not supported
[ https://issues.apache.org/jira/browse/IGNITE-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18664: -- Fix Version/s: 3.0.0-beta2 > Sql. subquery with OFFSET is not supported > -- > > Key: IGNITE-18664 > URL: https://issues.apache.org/jira/browse/IGNITE-18664 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18664) Sql. subquery with OFFSET is not supported
Maksim Zhuravkov created IGNITE-18664: - Summary: Sql. subquery with OFFSET is not supported Key: IGNITE-18664 URL: https://issues.apache.org/jira/browse/IGNITE-18664 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0.0-beta2 Reporter: Maksim Zhuravkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18663) Sql. DATE Literals are not validated correctly.
[
https://issues.apache.org/jira/browse/IGNITE-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18663:
--
Priority: Minor (was: Major)
> Sql. DATE Literals are not validated correctly.
> ---
>
> Key: IGNITE-18663
> URL: https://issues.apache.org/jira/browse/IGNITE-18663
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
>
> Date literal with incorrect are not rejected. Some examples:
> {code:java}
> # month out of range
> INSERT INTO dates VALUES ('1993-20-14')
> # day out of range
> INSERT INTO dates VALUES ('1993-08-99')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1993-02-29')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1900-02-29')
> {code}
> See more examples in test_incorrect_dates.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18663) Sql. DATE Literals are not validated correctly.
[
https://issues.apache.org/jira/browse/IGNITE-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18663:
--
Description:
Date literal with incorrect are not rejected. Some examples:
{code:java}
# month out of range
INSERT INTO dates VALUES ('1993-20-14')
# day out of range
INSERT INTO dates VALUES ('1993-08-99')
# day out of range because not a leapyear
INSERT INTO dates VALUES ('1993-02-29')
# day out of range because not a leapyear
INSERT INTO dates VALUES ('1900-02-29')
{code}
See more examples in test_incorrect_dates.test
was:
Date literal with incorrect are not rejected. Examples:
{code:java}
# month out of range
skipif ignite3
statement error
INSERT INTO dates VALUES ('1993-20-14')
# day out of range
skipif ignite3
statement error
INSERT INTO dates VALUES ('1993-08-99')
# day out of range because not a leapyear
skipif ignite3
statement error
INSERT INTO dates VALUES ('1993-02-29')
# day out of range because not a leapyear
skipif ignite3
statement error
INSERT INTO dates VALUES ('1900-02-29')
{code}
> Sql. DATE Literals are not validated correctly.
> ---
>
> Key: IGNITE-18663
> URL: https://issues.apache.org/jira/browse/IGNITE-18663
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
>
> Date literal with incorrect are not rejected. Some examples:
> {code:java}
> # month out of range
> INSERT INTO dates VALUES ('1993-20-14')
> # day out of range
> INSERT INTO dates VALUES ('1993-08-99')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1993-02-29')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1900-02-29')
> {code}
> See more examples in test_incorrect_dates.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18663) Sql. DATE Literals are not validated correctly.
Maksim Zhuravkov created IGNITE-18663:
-
Summary: Sql. DATE Literals are not validated correctly.
Key: IGNITE-18663
URL: https://issues.apache.org/jira/browse/IGNITE-18663
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Date literal with incorrect are not rejected. Examples:
{code:java}
# month out of range
skipif ignite3
statement error
INSERT INTO dates VALUES ('1993-20-14')
# day out of range
skipif ignite3
statement error
INSERT INTO dates VALUES ('1993-08-99')
# day out of range because not a leapyear
skipif ignite3
statement error
INSERT INTO dates VALUES ('1993-02-29')
# day out of range because not a leapyear
skipif ignite3
statement error
INSERT INTO dates VALUES ('1900-02-29')
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18662) Sql. Numeric to/from decimal cast with overflow does not produce an error
[
https://issues.apache.org/jira/browse/IGNITE-18662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18662:
--
Description:
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
Returns
{code:java}
100
{code}
And the following query:
{code:java}
SELECT 2147483648::DECIMAL(18,0)::INTEGER
-2147483648
# Integer.MIN_VALUE
{code}
{code:java}
query I
SELECT 128::DECIMAL(3,0)::TINYINT
-128
# Byte.MIN_VALUE
{code}
See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
was:
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
Returns
{code:java}
100
{code}
See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
> Sql. Numeric to/from decimal cast with overflow does not produce an error
> --
>
> Key: IGNITE-18662
> URL: https://issues.apache.org/jira/browse/IGNITE-18662
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Casts from numeric type to decimal with overflow must fail but they return a
> result:
> {code:java}
> SELECT 1000::BIGINT::DECIMAL(3,1)
> {code}
> Returns
> {code:java}
>
> 100
> {code}
> And the following query:
> {code:java}
> SELECT 2147483648::DECIMAL(18,0)::INTEGER
>
> -2147483648
> # Integer.MIN_VALUE
> {code}
> {code:java}
> query I
> SELECT 128::DECIMAL(3,0)::TINYINT
>
> -128
> # Byte.MIN_VALUE
> {code}
> See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18662) Sql. Numeric to/from decimal cast with overflow does not produce an error
[
https://issues.apache.org/jira/browse/IGNITE-18662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18662:
--
Summary: Sql. Numeric to/from decimal cast with overflow does not produce
an error (was: Sql. Numeric to decimal cast with overflow does not produce an
error)
> Sql. Numeric to/from decimal cast with overflow does not produce an error
> --
>
> Key: IGNITE-18662
> URL: https://issues.apache.org/jira/browse/IGNITE-18662
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Casts from numeric type to decimal with overflow must fail but they return a
> result:
> {code:java}
> SELECT 1000::BIGINT::DECIMAL(3,1)
> {code}
> Returns
> {code:java}
>
> 100
> {code}
> See skipif-ed examples in cast_to_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18662) Sql. Numeric to/from decimal cast with overflow does not produce an error
[
https://issues.apache.org/jira/browse/IGNITE-18662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18662:
--
Description:
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
Returns
{code:java}
100
{code}
See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
was:
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
Returns
{code:java}
100
{code}
See skipif-ed examples in cast_to_decimal.test
> Sql. Numeric to/from decimal cast with overflow does not produce an error
> --
>
> Key: IGNITE-18662
> URL: https://issues.apache.org/jira/browse/IGNITE-18662
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Casts from numeric type to decimal with overflow must fail but they return a
> result:
> {code:java}
> SELECT 1000::BIGINT::DECIMAL(3,1)
> {code}
> Returns
> {code:java}
>
> 100
> {code}
> See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18662) Sql. Numeric to decimal cast with overflow does not produce an error
[
https://issues.apache.org/jira/browse/IGNITE-18662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18662:
--
Description:
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
Returns
{code:java}
100
{code}
See skipif-ed examples in cast_to_decimal.test
was:
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
See skipif-ed examples in cast_to_decimal.test
> Sql. Numeric to decimal cast with overflow does not produce an error
>
>
> Key: IGNITE-18662
> URL: https://issues.apache.org/jira/browse/IGNITE-18662
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Casts from numeric type to decimal with overflow must fail but they return a
> result:
> {code:java}
> SELECT 1000::BIGINT::DECIMAL(3,1)
> {code}
> Returns
> {code:java}
>
> 100
> {code}
> See skipif-ed examples in cast_to_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18662) Sql. Numeric to decimal cast with overflow does not produce an error
Maksim Zhuravkov created IGNITE-18662:
-
Summary: Sql. Numeric to decimal cast with overflow does not
produce an error
Key: IGNITE-18662
URL: https://issues.apache.org/jira/browse/IGNITE-18662
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Casts from numeric type to decimal with overflow must fail but they return a
result:
{code:java}
SELECT 1000::BIGINT::DECIMAL(3,1)
{code}
See skipif-ed examples in cast_to_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18565) Modify getOrCreateMvPartition and getMvPartition of MvTableStorage to return the future
[ https://issues.apache.org/jira/browse/IGNITE-18565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-18565: - Epic Link: (was: IGNITE-17774) > Modify getOrCreateMvPartition and getMvPartition of MvTableStorage to return > the future > --- > > Key: IGNITE-18565 > URL: https://issues.apache.org/jira/browse/IGNITE-18565 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to make *MvTableStorage#getOrCreateMvPartition* and > *MvTableStorage#getMvPartition* return the > *CompletableFuture*. > Since, for example, we need to wait for the partition to be deleted before > creating / recreating it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18660) Sql. Decimal out of range error does not occur
[
https://issues.apache.org/jira/browse/IGNITE-18660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18660:
--
Description:
The following query is expected to fail but it does not.
{code:java}
statement error
SELECT ('0.54321543215432154321543215432154321'::DECIMAL(35,35) +
1)::VARCHAR
{code}
was:
Query
{code:java}
statement error
SELECT ('0.54321543215432154321543215432154321'::DECIMAL(35,35) +
1)::VARCHAR
{code}
> Sql. Decimal out of range error does not occur
> --
>
> Key: IGNITE-18660
> URL: https://issues.apache.org/jira/browse/IGNITE-18660
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query is expected to fail but it does not.
> {code:java}
> statement error
> SELECT ('0.54321543215432154321543215432154321'::DECIMAL(35,35) +
> 1)::VARCHAR
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18523) Destroy RocksDbTableStorage on destroy()
[
https://issues.apache.org/jira/browse/IGNITE-18523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-18523:
-
Epic Link: (was: IGNITE-17774)
> Destroy RocksDbTableStorage on destroy()
>
>
> Key: IGNITE-18523
> URL: https://issues.apache.org/jira/browse/IGNITE-18523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, {{#destroy()}} just stops the table storage, but, as it's used to
> implement table dropping, it should also destroy all the partitions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18661) Sql. Decimal multiplication could not be performed exactly: throw error
Maksim Zhuravkov created IGNITE-18661:
-
Summary: Sql. Decimal multiplication could not be performed
exactly: throw error
Key: IGNITE-18661
URL: https://issues.apache.org/jira/browse/IGNITE-18661
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following query is expected to fail but it does not.
{code:java}
SELECT '0.01'::DECIMAL(38,30) *
'0.01'::DECIMAL(38,30)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17915) Generalize support for inversion of control mechanisms
[
https://issues.apache.org/jira/browse/IGNITE-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682020#comment-17682020
]
Semyon Danilov commented on IGNITE-17915:
-
The PR seems good to me, however I need a second opinion from [~mmuzaf]
> Generalize support for inversion of control mechanisms
> ---
>
> Key: IGNITE-17915
> URL: https://issues.apache.org/jira/browse/IGNITE-17915
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.14
>Reporter: Łukasz Dywicki
>Assignee: Łukasz Dywicki
>Priority: Major
> Labels: patch-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Current inversion of control support for Ignite is bound to Spring framework
> and Spring ApplicationContext interface which is used to lookup beans by type
> or name.
> Above lookup criteria are fairly generic and can be used to first - extract,
> second - generalize support for foreign injections within Ignite itself. With
> little work it is possible to open this for further extensions. This is known
> pattern used in other Apache projects, ie.
> [{{BeanRepository}}|https://github.com/apache/camel/blob/camel-3.19.0/core/camel-api/src/main/java/org/apache/camel/spi/BeanRepository.java]
> and
> [{{Registry}}|https://github.com/apache/camel/blob/camel-3.19.0/core/camel-api/src/main/java/org/apache/camel/spi/Registry.java].
> Main motivation is Ignite running under OSGi which does not host Spring
> (Spring framework dropped support for OSGi a while ago), and has alternative
> ways to provide similar functionality. For OSGi there are mechanisms such as
> OSGi Blueprint and OSGi Service Registry itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18660) Sql. Decimal out of range error does not occur
Maksim Zhuravkov created IGNITE-18660:
-
Summary: Sql. Decimal out of range error does not occur
Key: IGNITE-18660
URL: https://issues.apache.org/jira/browse/IGNITE-18660
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Query
{code:java}
statement error
SELECT ('0.54321543215432154321543215432154321'::DECIMAL(35,35) +
1)::VARCHAR
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18498) InstallSnapshot request might be retried immediately
[
https://issues.apache.org/jira/browse/IGNITE-18498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-18498:
-
Epic Link: (was: IGNITE-17774)
> InstallSnapshot request might be retried immediately
>
>
> Key: IGNITE-18498
> URL: https://issues.apache.org/jira/browse/IGNITE-18498
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> {{InstallSnapshot}} request is repeated after the corresponding timeout if a
> response to the first request is not received in time. But in one test run,
> second {{InstallSnapshot}} request was sent 1 millisecond after the first one
> (before the response from the first one was received). This needs an
> investigation.
> See {{{}ItTableRaftSnapshotsTest{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
[
https://issues.apache.org/jira/browse/IGNITE-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18659:
--
Description:
Casting from one decimal type to another does not produce errors when
scale/precision is changed:
{code:java}
statement error
SELECT 10.00::DECIMAL(4,2)::DECIMAL(2,1);
{code}
See skipif-ed examples in decimal_decimal_overflow_cast.test
was:See skipif-ed examples in decimal_decimal_overflow_cast.test
> Sql. Decimal-decimal overflow cast error does not occur
> ---
>
> Key: IGNITE-18659
> URL: https://issues.apache.org/jira/browse/IGNITE-18659
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Casting from one decimal type to another does not produce errors when
> scale/precision is changed:
> {code:java}
> statement error
> SELECT 10.00::DECIMAL(4,2)::DECIMAL(2,1);
> {code}
> See skipif-ed examples in decimal_decimal_overflow_cast.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
[ https://issues.apache.org/jira/browse/IGNITE-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18659: -- Description: See skipif-ed examples in decimal_decimal_overflow_cast.test (was: # IGNITE-18658 Sql. Decimal overflow error is not raised) > Sql. Decimal-decimal overflow cast error does not occur > --- > > Key: IGNITE-18659 > URL: https://issues.apache.org/jira/browse/IGNITE-18659 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > > See skipif-ed examples in decimal_decimal_overflow_cast.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
[ https://issues.apache.org/jira/browse/IGNITE-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18659: -- Description: # IGNITE-18658 Sql. Decimal overflow error is not raised > Sql. Decimal-decimal overflow cast error does not occur > --- > > Key: IGNITE-18659 > URL: https://issues.apache.org/jira/browse/IGNITE-18659 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > > # IGNITE-18658 Sql. Decimal overflow error is not raised -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18658) Sql. Decimal overflow error is not raised in arithmetic operations
[
https://issues.apache.org/jira/browse/IGNITE-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18658:
--
Summary: Sql. Decimal overflow error is not raised in arithmetic operations
(was: Sql. Decimal overflow error is not raised)
> Sql. Decimal overflow error is not raised in arithmetic operations
> --
>
> Key: IGNITE-18658
> URL: https://issues.apache.org/jira/browse/IGNITE-18658
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> The following test cases are expected to fail
> {code:java}
> skipif ignite3
> statement error
> SELECT d+1000.0 FROM decimals
> skipif ignite3
> statement error
> SELECT -1000.0-d FROM decimals
> skipif ignite3
> statement error
> SELECT 2*d FROM decimals {code}
> There are other examples in decimal_overflow.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
[ https://issues.apache.org/jira/browse/IGNITE-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18659: -- Component/s: sql > Sql. Decimal-decimal overflow cast error does not occur > --- > > Key: IGNITE-18659 > URL: https://issues.apache.org/jira/browse/IGNITE-18659 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
Maksim Zhuravkov created IGNITE-18659: - Summary: Sql. Decimal-decimal overflow cast error does not occur Key: IGNITE-18659 URL: https://issues.apache.org/jira/browse/IGNITE-18659 Project: Ignite Issue Type: Bug Reporter: Maksim Zhuravkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
[ https://issues.apache.org/jira/browse/IGNITE-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18659: -- Labels: calcite2-required calcite3-required ignite-3 (was: ) > Sql. Decimal-decimal overflow cast error does not occur > --- > > Key: IGNITE-18659 > URL: https://issues.apache.org/jira/browse/IGNITE-18659 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18659) Sql. Decimal-decimal overflow cast error does not occur
[ https://issues.apache.org/jira/browse/IGNITE-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18659: -- Fix Version/s: 3.0.0-beta2 > Sql. Decimal-decimal overflow cast error does not occur > --- > > Key: IGNITE-18659 > URL: https://issues.apache.org/jira/browse/IGNITE-18659 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18658) Sql. Decimal overflow error is not raised
[
https://issues.apache.org/jira/browse/IGNITE-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18658:
--
Description:
The following test cases are expected to fail
{code:java}
skipif ignite3
statement error
SELECT d+1000.0 FROM decimals
skipif ignite3
statement error
SELECT -1000.0-d FROM decimals
skipif ignite3
statement error
SELECT 2*d FROM decimals {code}
There are other examples in decimal_overflow.test
was:
The following test cases are expected to fail
{code:java}
skipif ignite3
statement error
SELECT d+1000.0 FROM decimals
skipif ignite3
statement error
SELECT -1000.0-d FROM decimals
skipif ignite3
statement error
SELECT 2*d FROM decimals {code}
> Sql. Decimal overflow error is not raised
> -
>
> Key: IGNITE-18658
> URL: https://issues.apache.org/jira/browse/IGNITE-18658
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> The following test cases are expected to fail
> {code:java}
> skipif ignite3
> statement error
> SELECT d+1000.0 FROM decimals
> skipif ignite3
> statement error
> SELECT -1000.0-d FROM decimals
> skipif ignite3
> statement error
> SELECT 2*d FROM decimals {code}
> There are other examples in decimal_overflow.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18658) Sql. Decimal overflow error is not raised
[
https://issues.apache.org/jira/browse/IGNITE-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18658:
--
Summary: Sql. Decimal overflow error is not raised (was: Sql. Decimal
overflow is not occur)
> Sql. Decimal overflow error is not raised
> -
>
> Key: IGNITE-18658
> URL: https://issues.apache.org/jira/browse/IGNITE-18658
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> The following test cases are expected to fail
> {code:java}
> skipif ignite3
> statement error
> SELECT d+1000.0 FROM decimals
> skipif ignite3
> statement error
> SELECT -1000.0-d FROM decimals
> skipif ignite3
> statement error
> SELECT 2*d FROM decimals {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18658) Sql. Decimal overflow is not occur
[
https://issues.apache.org/jira/browse/IGNITE-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18658:
--
Summary: Sql. Decimal overflow is not occur (was: Sql. Decimal overflow is
not occures)
> Sql. Decimal overflow is not occur
> --
>
> Key: IGNITE-18658
> URL: https://issues.apache.org/jira/browse/IGNITE-18658
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> The following test cases are expected to fail
> {code:java}
> skipif ignite3
> statement error
> SELECT d+1000.0 FROM decimals
> skipif ignite3
> statement error
> SELECT -1000.0-d FROM decimals
> skipif ignite3
> statement error
> SELECT 2*d FROM decimals {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18658) Sql. Decimal overflow is not occures
[
https://issues.apache.org/jira/browse/IGNITE-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18658:
--
Summary: Sql. Decimal overflow is not occures (was: Sql. Decimal overflow
sometimes is not handled properly)
> Sql. Decimal overflow is not occures
>
>
> Key: IGNITE-18658
> URL: https://issues.apache.org/jira/browse/IGNITE-18658
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> The following test cases are expected to fail
> {code:java}
> skipif ignite3
> statement error
> SELECT d+1000.0 FROM decimals
> skipif ignite3
> statement error
> SELECT -1000.0-d FROM decimals
> skipif ignite3
> statement error
> SELECT 2*d FROM decimals {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18658) Sql. Decimal overflow
Maksim Zhuravkov created IGNITE-18658:
-
Summary: Sql. Decimal overflow
Key: IGNITE-18658
URL: https://issues.apache.org/jira/browse/IGNITE-18658
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following test cases are expected to fail
{code:java}
skipif ignite3
statement error
SELECT d+1000.0 FROM decimals
skipif ignite3
statement error
SELECT -1000.0-d FROM decimals
skipif ignite3
statement error
SELECT 2*d FROM decimals {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18658) Sql. Decimal overflow sometimes is not handled properly
[
https://issues.apache.org/jira/browse/IGNITE-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18658:
--
Summary: Sql. Decimal overflow sometimes is not handled properly (was:
Sql. Decimal overflow)
> Sql. Decimal overflow sometimes is not handled properly
> ---
>
> Key: IGNITE-18658
> URL: https://issues.apache.org/jira/browse/IGNITE-18658
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> The following test cases are expected to fail
> {code:java}
> skipif ignite3
> statement error
> SELECT d+1000.0 FROM decimals
> skipif ignite3
> statement error
> SELECT -1000.0-d FROM decimals
> skipif ignite3
> statement error
> SELECT 2*d FROM decimals {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18657) Sql. Decimal casts DECIMAL::VARCHAR
[
https://issues.apache.org/jira/browse/IGNITE-18657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18657:
--
Description:
The following test cases in test_decimal.test do not fail:
{code:java}
# any value >= 1 becomes out of range, though
skipif ignite3
statement error
SELECT '1'::DECIMAL(3, 3)::VARCHAR;
skipif ignite3
statement error
SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
# various error conditions
# scale must be bigger than or equal to width
skipif ignite3
statement error
SELECT '0.1'::DECIMAL(3, 4);
# width/scale out of range
skipif ignite3
statement error
SELECT '0.1'::DECIMAL(1000);
{code}
was:
The following test cases in test_decimal.test do not fail:
{code:java}
# any value >= 1 becomes out of range, though
skipif ignite3
statement error
SELECT '1'::DECIMAL(3, 3)::VARCHAR;
skipif ignite3
statement error
SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
{code}
> Sql. Decimal casts DECIMAL::VARCHAR
> ---
>
> Key: IGNITE-18657
> URL: https://issues.apache.org/jira/browse/IGNITE-18657
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following test cases in test_decimal.test do not fail:
> {code:java}
> # any value >= 1 becomes out of range, though
> skipif ignite3
> statement error
> SELECT '1'::DECIMAL(3, 3)::VARCHAR;
> skipif ignite3
> statement error
> SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
> # various error conditions
> # scale must be bigger than or equal to width
> skipif ignite3
> statement error
> SELECT '0.1'::DECIMAL(3, 4);
> # width/scale out of range
> skipif ignite3
> statement error
> SELECT '0.1'::DECIMAL(1000);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18657) Sql. Decimal casts DECIMAL::VARCHAR
Maksim Zhuravkov created IGNITE-18657:
-
Summary: Sql. Decimal casts DECIMAL::VARCHAR
Key: IGNITE-18657
URL: https://issues.apache.org/jira/browse/IGNITE-18657
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following test cases in test_decimal.test do not fail:
{code:java}
# any value >= 1 becomes out of range, though
skipif ignite3
statement error
SELECT '1'::DECIMAL(3, 3)::VARCHAR;
skipif ignite3
statement error
SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18657) Sql. Decimal casts DECIMAL::VARCHAR
[
https://issues.apache.org/jira/browse/IGNITE-18657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18657:
--
Labels: calcite2-required calcite3-required ignite-3 (was: )
> Sql. Decimal casts DECIMAL::VARCHAR
> ---
>
> Key: IGNITE-18657
> URL: https://issues.apache.org/jira/browse/IGNITE-18657
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following test cases in test_decimal.test do not fail:
> {code:java}
> # any value >= 1 becomes out of range, though
> skipif ignite3
> statement error
> SELECT '1'::DECIMAL(3, 3)::VARCHAR;
> skipif ignite3
> statement error
> SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18656) Sql. Decimal conversion in overflow: SELECT '9223372036854788.758'::DECIMAL;
Maksim Zhuravkov created IGNITE-18656:
-
Summary: Sql. Decimal conversion in overflow: SELECT
'9223372036854788.758'::DECIMAL;
Key: IGNITE-18656
URL: https://issues.apache.org/jira/browse/IGNITE-18656
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
{code:java}
# overflow in conversion
skipif ignite3
statement error
SELECT '9223372036854788.758'::DECIMAL; {code}
{code:java}
Not expected result at: (test_decimal.test:40). Statement: SELECT
'9223372036854788.758'::DECIMAL;. Error: an instance of java.lang.String ==>
Expected java.lang.Throwable to be thrown, but nothing was thrown.
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18656) Sql. Decimal conversion in overflow: SELECT '9223372036854788.758'::DECIMAL;
[
https://issues.apache.org/jira/browse/IGNITE-18656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18656:
--
Summary: Sql. Decimal conversion in overflow: SELECT
'9223372036854788.758'::DECIMAL; (was: Sql. Decimal conversion in overflow:
SELECT '9223372036854788.758'::DECIMAL; )
> Sql. Decimal conversion in overflow: SELECT '9223372036854788.758'::DECIMAL;
> -
>
> Key: IGNITE-18656
> URL: https://issues.apache.org/jira/browse/IGNITE-18656
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> # overflow in conversion
> skipif ignite3
> statement error
> SELECT '9223372036854788.758'::DECIMAL; {code}
> {code:java}
> Not expected result at: (test_decimal.test:40). Statement: SELECT
> '9223372036854788.758'::DECIMAL;. Error: an instance of java.lang.String ==>
> Expected java.lang.Throwable to be thrown, but nothing was thrown.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18655) Sql. CREATE TABLE with a column of a decimal type without parameters does not fail
[
https://issues.apache.org/jira/browse/IGNITE-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18655:
--
Priority: Minor (was: Major)
> Sql. CREATE TABLE with a column of a decimal type without parameters does not
> fail
> --
>
> Key: IGNITE-18655
> URL: https://issues.apache.org/jira/browse/IGNITE-18655
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> statement error
> CREATE TABLE decimals_without_params(d DECIMAL); {code}
> {code:java}
> Not expected result at: (test_decimal_ops.test:9). Statement: CREATE TABLE
> decimals_without_params(d DECIMAL);. Error: an instance of java.lang.String
> ==> Expected java.lang.Throwable to be thrown, but nothing was thrown
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18656) Sql. Decimal conversion in overflow: SELECT '9223372036854788.758'::DECIMAL
[
https://issues.apache.org/jira/browse/IGNITE-18656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18656:
--
Summary: Sql. Decimal conversion in overflow: SELECT
'9223372036854788.758'::DECIMAL (was: Sql. Decimal conversion in overflow:
SELECT '9223372036854788.758'::DECIMAL;)
> Sql. Decimal conversion in overflow: SELECT '9223372036854788.758'::DECIMAL
>
>
> Key: IGNITE-18656
> URL: https://issues.apache.org/jira/browse/IGNITE-18656
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> # overflow in conversion
> skipif ignite3
> statement error
> SELECT '9223372036854788.758'::DECIMAL; {code}
> {code:java}
> Not expected result at: (test_decimal.test:40). Statement: SELECT
> '9223372036854788.758'::DECIMAL;. Error: an instance of java.lang.String ==>
> Expected java.lang.Throwable to be thrown, but nothing was thrown.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18655) Sql. CREATE TABLE with a column of a decimal type without parameters does not fail
[
https://issues.apache.org/jira/browse/IGNITE-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18655:
--
Summary: Sql. CREATE TABLE with a column of a decimal type without
parameters does not fail (was: Sql. CREATE TABLE decimals_without_params(d
DECIMAL) should fail)
> Sql. CREATE TABLE with a column of a decimal type without parameters does not
> fail
> --
>
> Key: IGNITE-18655
> URL: https://issues.apache.org/jira/browse/IGNITE-18655
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> statement error
> CREATE TABLE decimals_without_params(d DECIMAL); {code}
> {code:java}
> Not expected result at: (test_decimal_ops.test:9). Statement: CREATE TABLE
> decimals_without_params(d DECIMAL);. Error: an instance of java.lang.String
> ==> Expected java.lang.Throwable to be thrown, but nothing was thrown
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18655) Sql. CREATE TABLE decimals_without_params(d DECIMAL) should fail
[
https://issues.apache.org/jira/browse/IGNITE-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18655:
--
Description:
{code:java}
statement error
CREATE TABLE decimals_without_params(d DECIMAL); {code}
{code:java}
Not expected result at: (test_decimal_ops.test:9). Statement: CREATE TABLE
decimals_without_params(d DECIMAL);. Error: an instance of java.lang.String ==>
Expected java.lang.Throwable to be thrown, but nothing was thrown
{code}
> Sql. CREATE TABLE decimals_without_params(d DECIMAL) should fail
>
>
> Key: IGNITE-18655
> URL: https://issues.apache.org/jira/browse/IGNITE-18655
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> statement error
> CREATE TABLE decimals_without_params(d DECIMAL); {code}
> {code:java}
> Not expected result at: (test_decimal_ops.test:9). Statement: CREATE TABLE
> decimals_without_params(d DECIMAL);. Error: an instance of java.lang.String
> ==> Expected java.lang.Throwable to be thrown, but nothing was thrown
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18655) Sql. CREATE TABLE decimals_without_params(d DECIMAL) should fail
Maksim Zhuravkov created IGNITE-18655: - Summary: Sql. CREATE TABLE decimals_without_params(d DECIMAL) should fail Key: IGNITE-18655 URL: https://issues.apache.org/jira/browse/IGNITE-18655 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18654) Sql. test_scan_big_varchar.test_slow incorrect results.
Maksim Zhuravkov created IGNITE-18654:
-
Summary: Sql. test_scan_big_varchar.test_slow incorrect results.
Key: IGNITE-18654
URL: https://issues.apache.org/jira/browse/IGNITE-18654
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
1)
{code:java}
query IIIR
SELECT COUNT(*), COUNT(a), MAX(CHARACTER_LENGTH(a)), SUM(CHARACTER_LENGTH(a))
FROM bigtable
8192 8192 1 8192.00 {code}
{code:java}
Not expected result at: (test_scan_big_varchar.test_slow:145). [row=0, col=0,
expected=8192, actual=15026] java.lang.AssertionError: Not expected result at:
(test_scan_big_varchar.test_slow:145). [row=0, col=0, expected=8192,
actual=15026]
{code}
2)
{code:java}
query IIIR
SELECT COUNT(*), COUNT(a), MAX(CHARACTER_LENGTH(a)), SUM(CHARACTER_LENGTH(a))
FROM bigtable
16384 16384 1 16384.00{code}
{code:java}
Not expected result at: (test_scan_big_varchar.test_slow:154). [row=0, col=0,
expected=16384, actual=40598] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18433) Full rebalance testing extension
[ https://issues.apache.org/jira/browse/IGNITE-18433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-18433: - Description: Scenarios for testing: (current storages: *TxStateStorage* and *MvPartitionStorage*) * During a full rebalance, the leader changes, what will happen? I expect the current rebalance to be canceled and a new one to start with empty storages and set initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. And also what index will be sent to the new leader, if during a full rebalancing on the recipient it will be equal to *-1*. * What happens if a leader changes during a full rebalance that has enough log to avoid a full rebalance? I expect the full rebalance to be canceled, clear the storages and set the initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. And also what index will be sent to the new leader, if during a full rebalancing on the recipient it will be equal to *-1*. * Suppose a full rebalancing for one of the storages ended successfully, and it has updated (not equal to -1) *lastAppliedIndex *and *lastAppliedTerm*, while for the other we did not have time to complete the full rebalancing and the node fell. What will happen to both storages after the node is powered on? I expect both stores to be cleared and have initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. Each scenario can be tested in a separate ticket was: Scenarios for testing: (current vaults: *TxStateStorage* and *MvPartitionStorage*) * During a full rebalance, the leader changes, what will happen? I expect the current rebalance to be canceled and a new one to start with empty storages and set initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. And also what index will be sent to the new leader, if during a full rebalancing on the recipient it will be equal to *-1*. * What happens if a leader changes during a full rebalance that has enough log to avoid a full rebalance? I expect the full rebalance to be canceled, clear the storages and set the initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. And also what index will be sent to the new leader, if during a full rebalancing on the recipient it will be equal to *-1*. * Suppose a full rebalancing for one of the storages ended successfully, and it has updated (not equal to -1) *lastAppliedIndex *and *lastAppliedTerm*, while for the other we did not have time to complete the full rebalancing and the node fell. What will happen to both storages after the node is powered on? I expect both stores to be cleared and have initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. Each scenario can be tested in a separate ticket > Full rebalance testing extension > > > Key: IGNITE-18433 > URL: https://issues.apache.org/jira/browse/IGNITE-18433 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Scenarios for testing: (current storages: *TxStateStorage* and > *MvPartitionStorage*) > * During a full rebalance, the leader changes, what will happen? > I expect the current rebalance to be canceled and a new one to start with > empty storages and set initial (equal to 0) *lastAppliedIndex *and > *lastAppliedTerm*. > And also what index will be sent to the new leader, if during a full > rebalancing on the recipient it will be equal to *-1*. > * What happens if a leader changes during a full rebalance that has enough > log to avoid a full rebalance? > I expect the full rebalance to be canceled, clear the storages and set the > initial (equal to 0) *lastAppliedIndex *and *lastAppliedTerm*. > And also what index will be sent to the new leader, if during a full > rebalancing on the recipient it will be equal to *-1*. > * Suppose a full rebalancing for one of the storages ended successfully, and > it has updated (not equal to -1) *lastAppliedIndex *and *lastAppliedTerm*, > while for the other we did not have time to complete the full rebalancing and > the node fell. > What will happen to both storages after the node is powered on? > I expect both stores to be cleared and have initial (equal to 0) > *lastAppliedIndex *and *lastAppliedTerm*. > Each scenario can be tested in a separate ticket -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18652) CdcMain is not committing state during index rebuilding
[ https://issues.apache.org/jira/browse/IGNITE-18652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-18652: --- Description: For persistent cluster CdcMain is not committing state during index rebuilding if there are no data updates. It can cause to sharp increase of cdc WAL-archive size in case of big indexes. Here is a reproducer patch: [^CdcRebuildTest.patch] was: For persistence enabled cluster CdcMain is not committing state during index rebuilding if there are no data updates. It can cause to sharp increase of cdc WAL-archive size in case of big indexes. Here is a reproducer patch: [^CdcRebuildTest.patch] > CdcMain is not committing state during index rebuilding > --- > > Key: IGNITE-18652 > URL: https://issues.apache.org/jira/browse/IGNITE-18652 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.14 >Reporter: Ilya Shishkov >Priority: Major > Labels: IEP-59, ise > Attachments: CdcRebuildTest.patch > > > For persistent cluster CdcMain is not committing state during index > rebuilding if there are no data updates. > It can cause to sharp increase of cdc WAL-archive size in case of big indexes. > Here is a reproducer patch: [^CdcRebuildTest.patch] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17554) {clientType}.ActiveSessions metrics are no updated in case of connection problems/lost
[
https://issues.apache.org/jira/browse/IGNITE-17554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-17554:
---
Assignee: Mikhail Petrov
> {clientType}.ActiveSessions metrics are no updated in case of connection
> problems/lost
> --
>
> Key: IGNITE-17554
> URL: https://issues.apache.org/jira/browse/IGNITE-17554
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Stepanov Ilya
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: ise
> Attachments: ProxyServer.java
>
>
> Metrics "\{clientType}.ActiveSessions" are not updated correctly in case of
> connection problems.
>
> Steps to reproduce:
> 1) Start server
> 2) Start jdbc or thin client
> 3) Block port 10800 on the server host
> {code:java}
> iptables -A INPUT -p tcp --dport 10800 -j DROP {code}
> 4) Check "\{clientType}.ActiveSessions". We will see one connection.
> 5) Stop jdbc or thin client
> 6) Check "\{clientType}.ActiveSessions". We will still see one connection in
> "\{clientType}.ActiveSessions".
> 7) After about 2 hours, the metric will have a negative value = -1
> Error in log:
> {code:java}
> [ERROR][grid-nio-worker-client-listener-1-#55][ClientListenerProcessor]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=DirectNioClient
> Worker [super=AbstractNioClientWorker [idx=1, bytesRcvd=19, bytesSent=28,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-client-listener-1, igniteInst
> anceName=null, finished=false, heartbeatTs=1661784642354, hashCode=624626958,
> interrupted=false, runner=grid-nio-worker-client-listener-1-#55]]],
> writeBuf=java.nio.DirectByteBuffer[po
> s=0 lim=23040 cap=23040], readBuf=java.nio.DirectByteBuffer[pos=0 lim=184640
> cap=184640], inRecovery=null, outRecovery=null, closeSocket=true,
> outboundMessagesQueueSizeMetric=o.a.i.i.
> processors.metric.impl.LongAdderMetric@63a61cb2, super=GridNioSessionImpl
> [locAddr=/10.40.6.205:10800, rmtAddr=/10.255.12.2:4708,
> createTime=1661776500783, closeTime=0, bytesSent=28,
> bytesRcvd=19, bytesSent0=0, bytesRcvd0=0, sndSchedTime=1661776500844,
> lastSndTime=1661776500844, lastRcvTime=1661776500833, readsPaused=false,
> filterChain=FilterChain[filters=[GridNio
> AsyncNotifyFilter, GridNioCodecFilter [parser=ClientListenerNioMessageParser,
> directMode=true]], accepted=true, markedForClose=false]]]
> java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[?:1.8.0_302]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[?:1.8.0_302]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> ~[?:1.8.0_302]
> at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[?:1.8.0_302]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[?:1.8.0_302]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1351)
> ~[ignite-core-2.13.1-p0.jar:2.13.1-p0]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2508)
> [ignite-core-2.13.1-p0.jar:2.13.1-p0]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2273)
> [ignite-core-2.13.1-p0.jar:2.13.1-p0]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1910)
> [ignite-core-2.13.1-p0.jar:2.13.1-p0]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-2.13.1-p0.jar:2.13.1-p0] {code}
>
> Another case with proxy:
>
> Steps to reproduce:
> 1) Start server
> 2) Start Proxy server for remote port 10800 and local port 1024
> 3) Start jdbc or thin client with proxy server connection
> {code:java}
> ClientConfiguration cfg = new
> ClientConfiguration().setAddresses("127.0.0.1:1024");
> IgniteClient igniteClient = Ignition.startClient(cfg);
> IgniteClient igniteClient2 = Ignition.startClient(cfg); {code}
> 4) Check "\{clientType}.ActiveSessions" and "views.CLIENT_CONNECTIONS". We
> will see one connection.
> 5) Stop jdbc or thin client
> 6) Stop Proxy server
> 7) Check "\{clientType}.ActiveSessions" and "views.CLIENT_CONNECTIONS".
> We will still see one connection in "\{clientType}.ActiveSessions" and no
> connection in "views.CLIENT_CONNECTIONS".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18653) Sql. The number of dynamic parameters can be checked once.
[ https://issues.apache.org/jira/browse/IGNITE-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18653: -- Description: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check in similar fashion for other queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are going to be no longer necessary after this change. was: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check in similar fashion for other queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are no longer necessary. > Sql. The number of dynamic parameters can be checked once. > -- > > Key: IGNITE-18653 > URL: https://issues.apache.org/jira/browse/IGNITE-18653 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite, calcite3-required, ignite-3 > > Since Apache Calcite's SqlParser maintains the number of dynamic parameters > internally (as a protected field) it is possible to simplify the check that > ensures that the number of dynamic parameters in a query is equal to the > number of provided parameters. > 1) See how that check is implemented for an SqlExplain in > IgniteSqlValidator::validate - it simply checks the number of dynamic > parameters in a query. We can implement that check in similar fashion for > other queries. > 2) Remove the redundant array of bound checks for dynamic parameters in > IgniteSqlValidator since they are going to be no longer necessary after this > change. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18653) Sql. The number of dynamic parameters can be checked once.
[ https://issues.apache.org/jira/browse/IGNITE-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18653: -- Fix Version/s: 3.0.0-beta2 > Sql. The number of dynamic parameters can be checked once. > -- > > Key: IGNITE-18653 > URL: https://issues.apache.org/jira/browse/IGNITE-18653 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite, calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > > Since Apache Calcite's SqlParser maintains the number of dynamic parameters > internally (as a protected field) it is possible to simplify the check that > ensures that the number of dynamic parameters in a query is equal to the > number of provided parameters. > 1) See how that check is implemented for an SqlExplain in > IgniteSqlValidator::validate - it simply checks the number of dynamic > parameters in a query. We can implement that check in similar fashion for > other queries. > 2) Remove the redundant array of bound checks for dynamic parameters in > IgniteSqlValidator since they are going to be no longer necessary after this > change. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18653) Sql. The number of dynamic parameters can be checked once.
[ https://issues.apache.org/jira/browse/IGNITE-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18653: -- Description: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check in similar fashion for other queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are no longer necessary. was: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check in similar fashion for other queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are no longer needed. > Sql. The number of dynamic parameters can be checked once. > -- > > Key: IGNITE-18653 > URL: https://issues.apache.org/jira/browse/IGNITE-18653 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite, calcite3-required, ignite-3 > > Since Apache Calcite's SqlParser maintains the number of dynamic parameters > internally (as a protected field) it is possible to simplify the check that > ensures that the number of dynamic parameters in a query is equal to the > number of provided parameters. > 1) See how that check is implemented for an SqlExplain in > IgniteSqlValidator::validate - it simply checks the number of dynamic > parameters in a query. We can implement that check in similar fashion for > other queries. > 2) Remove the redundant array of bound checks for dynamic parameters in > IgniteSqlValidator since they are no longer necessary. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18653) Sql. The number of dynamic parameters can be checked once.
[ https://issues.apache.org/jira/browse/IGNITE-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18653: -- Description: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check in similar fashion for other queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are no longer needed. was: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check for all types of queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are no longer needed. > Sql. The number of dynamic parameters can be checked once. > -- > > Key: IGNITE-18653 > URL: https://issues.apache.org/jira/browse/IGNITE-18653 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite, calcite3-required, ignite-3 > > Since Apache Calcite's SqlParser maintains the number of dynamic parameters > internally (as a protected field) it is possible to simplify the check that > ensures that the number of dynamic parameters in a query is equal to the > number of provided parameters. > 1) See how that check is implemented for an SqlExplain in > IgniteSqlValidator::validate - it simply checks the number of dynamic > parameters in a query. We can implement that check in similar fashion for > other queries. > 2) Remove the redundant array of bound checks for dynamic parameters in > IgniteSqlValidator since they are no longer needed. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18653) Sql. The number of dynamic parameters can be checked once.
[ https://issues.apache.org/jira/browse/IGNITE-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18653: -- Description: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. 1) See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check for all types of queries. 2) Remove the redundant array of bound checks for dynamic parameters in IgniteSqlValidator since they are no longer needed. was: Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check for all types of queries. > Sql. The number of dynamic parameters can be checked once. > -- > > Key: IGNITE-18653 > URL: https://issues.apache.org/jira/browse/IGNITE-18653 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite, calcite3-required, ignite-3 > > Since Apache Calcite's SqlParser maintains the number of dynamic parameters > internally (as a protected field) it is possible to simplify the check that > ensures that the number of dynamic parameters in a query is equal to the > number of provided parameters. > 1) See how that check is implemented for an SqlExplain in > IgniteSqlValidator::validate - it simply checks the number of dynamic > parameters in a query. We can implement that check for all types of queries. > 2) Remove the redundant array of bound checks for dynamic parameters in > IgniteSqlValidator since they are no longer needed. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18652) CdcMain is not committing state during index rebuilding
[ https://issues.apache.org/jira/browse/IGNITE-18652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-18652: --- Description: For persistence enabled cluster CdcMain is not committing state during index rebuilding if there are no data updates. It can cause to sharp increase of cdc WAL-archive size in case of big indexes. Here is a reproducer patch: [^CdcRebuildTest.patch] was: CdcMain is not committing state during index rebuilding if there are no data updates. It can cause to sharp increase of cdc WAL-archive size in case of big indexes. Here is a reproducer patch: [^CdcRebuildTest.patch] > CdcMain is not committing state during index rebuilding > --- > > Key: IGNITE-18652 > URL: https://issues.apache.org/jira/browse/IGNITE-18652 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.14 >Reporter: Ilya Shishkov >Priority: Major > Labels: IEP-59, ise > Attachments: CdcRebuildTest.patch > > > For persistence enabled cluster CdcMain is not committing state during index > rebuilding if there are no data updates. > It can cause to sharp increase of cdc WAL-archive size in case of big indexes. > Here is a reproducer patch: [^CdcRebuildTest.patch] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18653) Sql. The number of dynamic parameters can be checked once.
Maksim Zhuravkov created IGNITE-18653: - Summary: Sql. The number of dynamic parameters can be checked once. Key: IGNITE-18653 URL: https://issues.apache.org/jira/browse/IGNITE-18653 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Since Apache Calcite's SqlParser maintains the number of dynamic parameters internally (as a protected field) it is possible to simplify the check that ensures that the number of dynamic parameters in a query is equal to the number of provided parameters. See how that check is implemented for an SqlExplain in IgniteSqlValidator::validate - it simply checks the number of dynamic parameters in a query. We can implement that check for all types of queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18422) Sql. Match number of dynamic parameters with given parameters
[
https://issues.apache.org/jira/browse/IGNITE-18422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18422:
--
Labels: calcite2-required ignite-3 (was: calcite2-required
calcite3-required ignite-3)
> Sql. Match number of dynamic parameters with given parameters
> -
>
> Key: IGNITE-18422
> URL: https://issues.apache.org/jira/browse/IGNITE-18422
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> User can run SQL query with dynamic parameter and forget to pass the
> parameters, or pass wrong number of parameters. Need to check it on
> validation stage and rise properly error.
> As example:
> {code:java}
> assertQuery("SELECT COALESCE(?, ?)").withParams("a").returns("a").check();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18168) SQL: incorrect sum of several FLOAT values
[
https://issues.apache.org/jira/browse/IGNITE-18168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-18168:
-
Assignee: Andrey Mashenkov
> SQL: incorrect sum of several FLOAT values
> --
>
> Key: IGNITE-18168
> URL: https://issues.apache.org/jira/browse/IGNITE-18168
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> This behavior seems incorrect:
> {code:sql}
> create table xx (key_field INT PRIMARY KEY,field2 FLOAT);
> insert into xx (key_field,field2) values (1, 10);
> insert into xx (key_field,field2) values (2, 5);
> insert into xx (key_field,field2) values (3, 3);
> insert into xx (key_field,field2) values (4, 5.1);
> insert into xx (key_field,field2) values (5, 3);
> insert into xx (key_field,field2) values (6, 4);
> insert into xx (key_field,field2) values (7, 2);
> insert into xx (key_field,field2) values (8, 8);
> insert into xx (key_field,field2) values (9, 3);
> insert into xx (key_field,field2) values (10,9);
> insert into xx (key_field,field2) values (11,9);
> SELECT SUM(field2) FROM xx;
> --> returns 61.1015625, expected 61.1
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
