[jira] [Updated] (IGNITE-17151) Inconsistent keys after deletion during rebalance
[ https://issues.apache.org/jira/browse/IGNITE-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17151: --- Attachment: DeletionDuringRebalanceTest.java > Inconsistent keys after deletion during rebalance > - > > Key: IGNITE-17151 > URL: https://issues.apache.org/jira/browse/IGNITE-17151 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Attachments: DeletionDuringRebalanceTest.java > > > Scenario: > # Stop a node > # Load data while the node is still offline > # Start the node > # While the node is online and rebalancing delete objects > # Wait for the node to complete rebalancing and verified the partitions via > partition_reconciliation > Reproduced is attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17151) Inconsistent keys after deletion during rebalance
[ https://issues.apache.org/jira/browse/IGNITE-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-17151: -- Assignee: Vladislav Pyatkov > Inconsistent keys after deletion during rebalance > - > > Key: IGNITE-17151 > URL: https://issues.apache.org/jira/browse/IGNITE-17151 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > > Scenario: > # Stop a node > # Load data while the node is still offline > # Start the node > # While the node is online and rebalancing delete objects > # Wait for the node to complete rebalancing and verified the partitions via > partition_reconciliation > Reproduced is attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17151) Inconsistent keys after deletion during rebalance
Vladislav Pyatkov created IGNITE-17151: -- Summary: Inconsistent keys after deletion during rebalance Key: IGNITE-17151 URL: https://issues.apache.org/jira/browse/IGNITE-17151 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov Scenario: # Stop a node # Load data while the node is still offline # Start the node # While the node is online and rebalancing delete objects # Wait for the node to complete rebalancing and verified the partitions via partition_reconciliation Reproduced is attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552307#comment-17552307 ] Anton Vinogradov edited comment on IGNITE-15834 at 6/9/22 4:26 PM: --- Merged to the master. [~nizhikov] , thanks for the review! was (Author: av): Merged to the master. [~nizhikov] , thenks for the review! > Read Repair should support arrays and collections as values > --- > > Key: IGNITE-15834 > URL: https://issues.apache.org/jira/browse/IGNITE-15834 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552307#comment-17552307 ] Anton Vinogradov commented on IGNITE-15834: --- Merged to the master. [~nizhikov] , thenks for the review! > Read Repair should support arrays and collections as values > --- > > Key: IGNITE-15834 > URL: https://issues.apache.org/jira/browse/IGNITE-15834 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834 ]
Anton Vinogradov deleted comment on IGNITE-15834:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10047/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10047/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6596898buildTypeId=IgniteTests24Java8_RunAll]
> Read Repair should support arrays and collections as values
> ---
>
> Key: IGNITE-15834
> URL: https://issues.apache.org/jira/browse/IGNITE-15834
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.14
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-15834) Read Repair should support arrays and collections as values
[
https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552302#comment-17552302
]
Ignite TC Bot commented on IGNITE-15834:
{panel:title=Branch: [pull/10047/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10047/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6620224buildTypeId=IgniteTests24Java8_RunAll]
> Read Repair should support arrays and collections as values
> ---
>
> Key: IGNITE-15834
> URL: https://issues.apache.org/jira/browse/IGNITE-15834
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.14
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*,
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
was:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> *org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*,
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
was:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
{*}Implementation proposal{*}
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
{*}Implementation proposal{*}
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
was:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
{*}Implementation proposal{*}{*}{*}
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
{*}Implementation proposal{*}{*}{*}
Divide by two (in-memory and persistent):
*
*org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
*
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
* *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
was:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples.
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> {code:java}
> CREATE TABLE user (id INT PRIMARY
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples.
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory
> {code}
> *Implementation proposal*
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
was:
*Problem*
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
*Implementation proposal*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples.
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory
> {code}
> *Implementation proposal*
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples.
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory
{code}
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
*
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory{code}
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples.
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
*
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory{code}
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory{code}
123
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples:
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> *
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory{code}
123
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory{code}
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples:
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory{code}
> 123
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory{code}
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory {code}
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples:
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17123) Fix wrong update counter assignment on backup nodes for noop invoke operation.
[
https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552276#comment-17552276
]
Ignite TC Bot commented on IGNITE-17123:
{panel:title=Branch: [pull/10075/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10075/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 9{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6620265]]
* {color:#013220}IgniteCacheTestSuite9:
TxPartitionCounterStateConsistencyNoopInvokeTest.testPartitionConsistencyAfterNoopInvoke[concurrency=PESSIMISTIC,
isolation=REPEATABLE_READ] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite9:
TxPartitionCounterStateConsistencyNoopInvokeTest.testPartitionConsistencyAfterNoopInvoke[concurrency=PESSIMISTIC,
isolation=READ_COMMITTED] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite9:
TxPartitionCounterStateConsistencyNoopInvokeTest.testPartitionConsistencyAfterNoopInvoke[concurrency=PESSIMISTIC,
isolation=SERIALIZABLE] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite9:
TxPartitionCounterStateConsistencyNoopInvokeTest.testPartitionConsistencyAfterNoopInvoke[concurrency=OPTIMISTIC,
isolation=REPEATABLE_READ] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite9:
TxPartitionCounterStateConsistencyNoopInvokeTest.testPartitionConsistencyAfterNoopInvoke[concurrency=OPTIMISTIC,
isolation=READ_COMMITTED] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite9:
TxPartitionCounterStateConsistencyNoopInvokeTest.testPartitionConsistencyAfterNoopInvoke[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6620337buildTypeId=IgniteTests24Java8_RunAll]
> Fix wrong update counter assignment on backup nodes for noop invoke operation.
> --
>
> Key: IGNITE-17123
> URL: https://issues.apache.org/jira/browse/IGNITE-17123
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Minor
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Transaction reserves partition counters on primary.
> On the backup side, TxEntries must be commited with counters from the
> reserved range.
> However, a range of update counters, which were reserved on primary, is NOT
> validated on backup. Thus means NOOP invoke operation may cause partition
> counter difference on the primary and backup nodes.
> 1. Let's pass NOOP result of invoke operation to the backup and avoid
> incorrect partition counter change on backup nodes (see DhtTxPrepareFuture).
> 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote
> node (for the WAL purposes) instead of allocating+iterating over a new
> collection (see GridDistributedTxRemoteAdapter.commitIfLocked).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
* When creating a table through SQL, it would be more convenient for the user
to simply specify the engine and use the default region than specify the data
region, let's look at the examples:
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='in-memory'
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
dataRegion='persistnet'{code}
**
{code:java}
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
in-memory-pagememory
CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
persistnet-pagememory {code}
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples:
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> **
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17150) Add ENCRYPTED_OUT_OF_ORDER_UPDATE WAL record type placeholder
Vyacheslav Koptilin created IGNITE-17150: Summary: Add ENCRYPTED_OUT_OF_ORDER_UPDATE WAL record type placeholder Key: IGNITE-17150 URL: https://issues.apache.org/jira/browse/IGNITE-17150 Project: Ignite Issue Type: Improvement Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.14 Reserve new WAL type for encrypted OUT_OF_ORDER_UPDATE record. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17149:
-
Description:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
* *PageMemoryDataRegionConfigurationSchema* contains the configuration for
in-memory and the persistent case, which can be confusing because it's not
obvious which properties to set for each;
* User does not have the ability to set a different size
*PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
persistent case;
*
was:
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
*
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> {*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> *
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17075) Cache 6 suite timeouts sporadically
[ https://issues.apache.org/jira/browse/IGNITE-17075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17075: - Fix Version/s: 2.14 > Cache 6 suite timeouts sporadically > --- > > Key: IGNITE-17075 > URL: https://issues.apache.org/jira/browse/IGNITE-17075 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Let’s investigate and fix this. > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E=overview=builds -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
Kirill Tkalenko created IGNITE-17149:
Summary: Separation of the
PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
Key: IGNITE-17149
URL: https://issues.apache.org/jira/browse/IGNITE-17149
Project: Ignite
Issue Type: Task
Reporter: Kirill Tkalenko
Fix For: 3.0.0-alpha6
At the moment, the
*org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
contains configuration for in-memory and persistent
{*}org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema{*},
which can be inconvenient for the user for several reasons:
*
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-17148:
Assignee: (was: Kirill Tkalenko)
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the PageMemory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch an example scheme.
> {code:java}
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> How can we implement this at the moment:
> * internal extension of the configuration: then the user will not be able to
> see and change it - not suitable;
> * polymorphic configuration:
> ** by design, we cannot create root config schemas for polymorphic config or
> instances;
> ** by design, we can change the type of polymorphic configuration to any
> instance, we do not fix its type, which does not suit us;
> ** by design, we cannot expose a polymorphic instance as a configuration
> schema property;
> ** hocon will display the type of polymorphic configuration, which is not
> necessary in this case and will look a little strange.
> The possible options do not suit us, so I propose to add another solution.
> *Proposal*
> Add an abstract configuration schema from which we can inherit, add
> properties, but only its heirs could be used as properties of other
> configurations schemas or configuration roots. Unlike a polymorphic
> configuration, it will not store and display the type in hocon, and the type
> cannot be changed.
> The abstract configuration schema from which will be inherited will contain
> the annotation {*}@AbstractConfiguration{*}, and any successor must extend it
> and contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
> {code:java}
> @AbstractConfiguration
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @Config
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> *Further development*
> * Merge with internal configuration extension;
> * Consider joining with a polymorphic configuration.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
The possible options do not suit us, so I propose to add another solution.
*Proposal*
Add an abstract configuration schema from which we can inherit, add properties,
but only its heirs could be used as properties of other configurations schemas
or configuration roots. Unlike a polymorphic configuration, it will not store
and display the type in hocon, and the type cannot be changed.
The abstract configuration schema from which will be inherited will contain the
annotation {*}@AbstractConfiguration{*}, and any successor must extend it and
contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
{code:java}
@AbstractConfiguration
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@Config
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
*Further development*
* Merge with internal configuration extension;
* Consider joining with a polymorphic configuration.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
The possible options do not suit us, so I propose to add another solution.
*Proposal*
Add an abstract configuration schema from which we can inherit, add properties,
but only its heirs could be used as properties of other configurations schemas
or configuration roots. Unlike a polymorphic configuration, it will not store
and display the type in hocon, and the type cannot be changed.
The abstract configuration schema from which will be inherited will contain the
annotation {*}@AbstractConfiguration{*}, and any successor must extend it and
contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
{code:java}
@AbstractConfiguration
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@Config
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
*Further development*
* Merge with internal configuration extension;
* Consider joining with a polymorphic configuration.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
The possible options do not suit us, so I propose to add another solution.
*Proposal*
Add an abstract configuration schema from which we can inherit, add properties,
but only its heirs could be used as properties of other configurations schemas
or configuration roots. Unlike a polymorphic configuration, it will not store
and display the type in hocon, and the type cannot be changed.
The abstract configuration schema from which will be inherited will contain the
annotation {*}@AbstractConfiguration{*}, and any successor must extend it and
contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
{code:java}
@AbstractConfiguration
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@Config
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED) \
public class
[jira] [Updated] (IGNITE-17112) Consistency check must fix counter after the consistency fix
[
https://issues.apache.org/jira/browse/IGNITE-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-17112:
-
Labels: ise (was: )
> Consistency check must fix counter after the consistency fix
>
>
> Key: IGNITE-17112
> URL: https://issues.apache.org/jira/browse/IGNITE-17112
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
>
> Consistency repair repairs the consistency for the data committed on at least
> single node.
> But partition counter may have gaps for prepared, but not committed data, and
> such gaps will cause exception on cluster activation:
> {noformat}
> 2022-06-03 22:01:59.695
> [ERROR][sys-#322][org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager]
> Failed to update partition counter. Most probably a node with most actual
> data is out of topology or data streamer is used in preload mode
> (allowOverride=false) concurrently with cache transactions [grpName=XXX,
> partId=9099]
> org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=4854911, curState=Counter [lwm=4854911, holes={4854912=Item
> [start=4854912, delta=1]}, maxApplied=4854913, hwm=4854911]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:153)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.update(PartitionUpdateCounterErrorWrapper.java:97)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1687)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2530)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:913)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1491)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.lambda$updatePartitionFullMap$81bdb8e8$1(GridDhtPartitionsExchangeFuture.java:4817)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:11358)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_322]
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Consistency check via cli must close this gaps on successful consistency
> repair.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
@ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
@ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED) \
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the PageMemory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the PageMemory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch an
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the Memory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch an
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
*
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the Memory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Description:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* internal extension of the configuration: then the user will not be able to
see and change it - not suitable;
* polymorphic configuration:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
*
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
was:
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* [internal extension of the
configuration|https://issues.apache.org/jira/browse/IGNITE-15047]: then the
user will not be able to see and change it - not suitable;
* [polymorphic
configuration|https://issues.apache.org/jira/browse/IGNITE-14645]:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the Memory based storage
>
[jira] [Created] (IGNITE-17148) Support for abstract configuration
Kirill Tkalenko created IGNITE-17148:
Summary: Support for abstract configuration
Key: IGNITE-17148
URL: https://issues.apache.org/jira/browse/IGNITE-17148
Project: Ignite
Issue Type: Task
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 3.0.0-alpha6
*NOTE*
Description may not be complete.
*Problem*
We need the ability to create a basic configuration schema so that we can
define a common configuration schema and inherit from it with additional
configuration added.
Let's look at an example:
We need to create two configuration schemes for the Memory based storage
engine, they should have a common property "page size in bytes" and then they
should be different, let's sketch an example scheme.
{code:java}
public class BasePageMemoryStorageEngineConfigurationSchema {
@Value(hasDefault = true)
public int pageSize = 16 * 1024;
}
public class VolatilePageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public VolatilePageMemoryDataRegionConfigurationSchema regions;
}
public class PersistentPageMemoryStorageEngineConfigurationSchema extends
BasePageMemoryStorageEngineConfigurationSchema{
@ConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
@NamedConfigValue
public PersistentPageMemoryDataRegionConfigurationSchema regions;
@ConfigValue
public PageMemoryCheckpointConfigurationSchema checkpoint;
}{code}
How can we implement this at the moment:
* [internal extension of the
configuration|https://issues.apache.org/jira/browse/IGNITE-15047]: then the
user will not be able to see and change it - not suitable;
* [polymorphic
configuration|https://issues.apache.org/jira/browse/IGNITE-14645]:
** by design, we cannot create root config schemas for polymorphic config or
instances;
** by design, we can change the type of polymorphic configuration to any
instance, we do not fix its type, which does not suit us;
** by design, we cannot expose a polymorphic instance as a configuration
schema property;
** hocon will display the type of polymorphic configuration, which is not
necessary in this case and will look a little strange.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17124) Storage API tests can't be used for storages with specific binary format
[ https://issues.apache.org/jira/browse/IGNITE-17124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17124: - Reviewer: Kirill Tkalenko > Storage API tests can't be used for storages with specific binary format > > > Key: IGNITE-17124 > URL: https://issues.apache.org/jira/browse/IGNITE-17124 > Project: Ignite > Issue Type: Improvement >Reporter: Timur Magomedov >Assignee: Timur Magomedov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 2h > Remaining Estimate: 0h > > Storages that need to get table UUID or rely on some specific binary format > of DataRow can't be tested using AbstractPartitionStorageTest. This works for > key-value storages that don't decode key and value of DataRow/SearchRow and > don't use table UUID but will fail once such storages are implemented or > existing ones will decode data binaries. > Two main issues here are the following: > 1. searchRow() and dataRow() methods in AbstractPartitionStorageTest can't be > overridden since they are static methods. > 2. Table UUID is always null in Storage API tests. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17147) Ignite should not talk to kubernetes default service to get its own IP
laptimus created IGNITE-17147: - Summary: Ignite should not talk to kubernetes default service to get its own IP Key: IGNITE-17147 URL: https://issues.apache.org/jira/browse/IGNITE-17147 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.11.1 Environment: Kubernetes Reporter: laptimus Ignite should not talk to kubernetes default service to get its own IP We have kubernetes cluster with calico network policies and seems like ignite is the only application in our cluster that needs access to kubernetes default service I see this as a security risk Please implement an alternative way in IP Finder as that the class that talks to kubernetes default service to know pod IP address thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17131) Wrong result if subquery is on the left child of LEFT JOIN operator
[
https://issues.apache.org/jira/browse/IGNITE-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552199#comment-17552199
]
Ignite TC Bot commented on IGNITE-17131:
{panel:title=Branch: [pull/10077/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10077/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1 (lazy=true){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6617415]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
GridSubqueryJoinOptimizerSelfTest.testOptimizationLeftJoinSubqueryOnLeft -
PASSED{color}
{color:#8b}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6619709]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridSubqueryJoinOptimizerSelfTest.testOptimizationLeftJoinSubqueryOnLeft -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6617420buildTypeId=IgniteTests24Java8_RunAll]
> Wrong result if subquery is on the left child of LEFT JOIN operator
> ---
>
> Key: IGNITE-17131
> URL: https://issues.apache.org/jira/browse/IGNITE-17131
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently a query with a filtering subquery of a left side of a LEFT JOIN
> returns an invalid result. Looks like the problem is somewhere inside
> {{{}GridSubqueryJoinOptimizer{}}}.
> The possible workaround is to turn the join rewriting off by setting the
> system property {{IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION}} to false.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552184#comment-17552184
]
Semyon Danilov edited comment on IGNITE-17144 at 6/9/22 12:39 PM:
--
The patch looks good to me, merged to:
* `main` branch -- 30a2d9fffe91b60fd8a73f82c9dbfa6c04c33989
* `ignite-3.0.0-alpha5` branch -- ab60e7678a70efddf6f88742e2b309429b8e
Thank you for the contribution
was (Author: sdanilov):
The patch looks good to me, merged to:
* `main` branch -- 30a2d9fffe91b60fd8a73f82c9dbfa6c04c33989
* `ignite-3.0.0-alpha5` branch -- ab60e7678a70efddf6f88742e2b309429b8e
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> {{java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5}}
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552184#comment-17552184
]
Semyon Danilov commented on IGNITE-17144:
-
The patch looks good to me, merged to:
* `main` branch -- 30a2d9fffe91b60fd8a73f82c9dbfa6c04c33989
* `ignite-3.0.0-alpha5` branch -- ab60e7678a70efddf6f88742e2b309429b8e
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> {{java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5}}
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552171#comment-17552171
]
Kirill Tkalenko commented on IGNITE-17144:
--
[~apolovtcev] Looks good to me.
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> {{java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5}}
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17144:
-
Reviewer: Kirill Tkalenko
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> {{java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5}}
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17146) Add support for alpha, beta, etc. releases in IgniteProductVersion
[
https://issues.apache.org/jira/browse/IGNITE-17146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17146:
-
Description:
{code:java}
org.apache.ignite.internal.properties.IgniteProductVersion#alphaVersion{code}
has been added for the upcoming 3.0.0-alpha5 release, we need to fix it so that
we can work with alpha, beta and other releases.
was:A field has been added for the upcoming 3.0.0-alpha5 release, we need to
fix it so that we can work with alpha, beta and other releases.
> Add support for alpha, beta, etc. releases in IgniteProductVersion
> --
>
> Key: IGNITE-17146
> URL: https://issues.apache.org/jira/browse/IGNITE-17146
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> {code:java}
> org.apache.ignite.internal.properties.IgniteProductVersion#alphaVersion{code}
> has been added for the upcoming 3.0.0-alpha5 release, we need to fix it so
> that we can work with alpha, beta and other releases.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17146) Add support for alpha, beta, etc. releases in IgniteProductVersion
Kirill Tkalenko created IGNITE-17146: Summary: Add support for alpha, beta, etc. releases in IgniteProductVersion Key: IGNITE-17146 URL: https://issues.apache.org/jira/browse/IGNITE-17146 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Fix For: 3.0.0-alpha6 A field has been added for the upcoming 3.0.0-alpha5 release, we need to fix it so that we can work with alpha, beta and other releases. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17145) Fix handle BinaryObjectException at the thin JDBC
Taras Ledkov created IGNITE-17145:
-
Summary: Fix handle BinaryObjectException at the thin JDBC
Key: IGNITE-17145
URL: https://issues.apache.org/jira/browse/IGNITE-17145
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.13
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.14
I am trying to get enum field using sqlline, but failed with error Statement is
closed.
{code}
0: jdbc:ignite:thin://127.0.0.1> select status from nebulaclusterinfo;
Error: Statement is closed. (state=,code=0)
java.sql.SQLException: Statement is closed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.ensureNotClosed(JdbcThinStatement.java:950)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.getWarnings(JdbcThinStatement.java:546)
at sqlline.Commands.execute(Commands.java:849)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://127.0.0.1> select count(status) from nebulaclusterinfo;
++
| COUNT(STATUS) |
++
| 310|
++
1 row selected (0.108 seconds)
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17145) Fix handle BinaryObjectException at the thin JDBC
[
https://issues.apache.org/jira/browse/IGNITE-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552137#comment-17552137
]
Taras Ledkov commented on IGNITE-17145:
---
*Root cause:*
Thin JDBC driver handles BinaryObjectException invalid: closes connection.
*Proposal fix:*
Do nothing with defaults keepBinary mode,
Handles BinaryObjectException properly.
> Fix handle BinaryObjectException at the thin JDBC
> -
>
> Key: IGNITE-17145
> URL: https://issues.apache.org/jira/browse/IGNITE-17145
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.13
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
>
> I am trying to get enum field using sqlline, but failed with error Statement
> is closed.
> {code}
> 0: jdbc:ignite:thin://127.0.0.1> select status from nebulaclusterinfo;
> Error: Statement is closed. (state=,code=0)
> java.sql.SQLException: Statement is closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.ensureNotClosed(JdbcThinStatement.java:950)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.getWarnings(JdbcThinStatement.java:546)
> at sqlline.Commands.execute(Commands.java:849)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1> select count(status) from nebulaclusterinfo;
> ++
> | COUNT(STATUS) |
> ++
> | 310|
> ++
> 1 row selected (0.108 seconds)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-17144:
Fix Version/s: 3.0.0-alpha5
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> {{java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5}}
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17137) Move ignite-cloud to the Ignite Extensions project
[ https://issues.apache.org/jira/browse/IGNITE-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552131#comment-17552131 ] Amelchev Nikita commented on IGNITE-17137: -- [~mmuzaf], LGTM. > Move ignite-cloud to the Ignite Extensions project > -- > > Key: IGNITE-17137 > URL: https://issues.apache.org/jira/browse/IGNITE-17137 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Move ignite-cloud to the Ignite Extensions project -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
Aleksandr Polovtcev created IGNITE-17144:
Summary: IgniteProductVersion is unable to parse "3.0.0-alpha5"
string
Key: IGNITE-17144
URL: https://issues.apache.org/jira/browse/IGNITE-17144
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
When trying to build the alpha release of Ignite 3, we are getting the
following error:
```
java.lang.IllegalArgumentException: Unexpected Ignite version format:
3.0.0-alpha5
```
We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17144:
-
Description:
When trying to build the alpha release of Ignite 3, we are getting the
following error:
{{java.lang.IllegalArgumentException: Unexpected Ignite version format:
3.0.0-alpha5}}
We need to update the regex inside the {{IgniteProductVersion}} class.
was:
When trying to build the alpha release of Ignite 3, we are getting the
following error:
java.lang.IllegalArgumentException: Unexpected Ignite version format:
3.0.0-alpha5
```
We need to update the regex inside the {{IgniteProductVersion}} class.
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> {{java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5}}
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17144) IgniteProductVersion is unable to parse "3.0.0-alpha5" string
[
https://issues.apache.org/jira/browse/IGNITE-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17144:
-
Description:
When trying to build the alpha release of Ignite 3, we are getting the
following error:
java.lang.IllegalArgumentException: Unexpected Ignite version format:
3.0.0-alpha5
```
We need to update the regex inside the {{IgniteProductVersion}} class.
was:
When trying to build the alpha release of Ignite 3, we are getting the
following error:
```
java.lang.IllegalArgumentException: Unexpected Ignite version format:
3.0.0-alpha5
```
We need to update the regex inside the {{IgniteProductVersion}} class.
> IgniteProductVersion is unable to parse "3.0.0-alpha5" string
> -
>
> Key: IGNITE-17144
> URL: https://issues.apache.org/jira/browse/IGNITE-17144
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> When trying to build the alpha release of Ignite 3, we are getting the
> following error:
> java.lang.IllegalArgumentException: Unexpected Ignite version format:
> 3.0.0-alpha5
> ```
> We need to update the regex inside the {{IgniteProductVersion}} class.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17036) RaftException: ESTATEMACHINE:null when change replicas from 3 to 2 for a table
[
https://issues.apache.org/jira/browse/IGNITE-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17036:
-
Description:
Reproducer on a feature branch ignite-14209 :
{code:java}
void testOneRebalance(@WorkDirectory Path workDir, TestInfo testInfo) throws
Exception {
TableDefinition schTbl1 = SchemaBuilders.tableBuilder("PUBLIC",
"tbl1").columns(
SchemaBuilders.column("key", ColumnType.INT64).build(),
SchemaBuilders.column("val",
ColumnType.INT32).asNullable(true).build()
).withPrimaryKey("key").build();
nodes.get(0).tableManager.createTable(
"PUBLIC.tbl1",
tblChanger -> SchemaConfigurationConverter.convert(schTbl1,
tblChanger)
.changeReplicas(1)
.changePartitions(1));
assertEquals(1,
nodes.get(0).clusterCfgMgr.configurationRegistry().getConfiguration(TablesConfiguration.KEY)
.tables().get("PUBLIC.TBL1").replicas().value());
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(3));
waitPartitionAssignmentsSyncedToExpected(0, 3);
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(2));
waitPartitionAssignmentsSyncedToExpected(0, 2);
assertEquals(3, getAssignments(0, 0).size());
assertEquals(3, getAssignments(1, 0).size());
assertEquals(3, getAssignments(2, 0).size());
}
{code}
This code hangs with
{noformat}
2022-05-26 12:14:00:871 +0300 [ERROR][Thread-89][MetaStorageServiceImpl]
Unexpected exception
java.util.concurrent.CompletionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: ESTATEMACHINE:null
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:617)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:556)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: class org.apache.ignite.raft.jraft.rpc.impl.RaftException:
ESTATEMACHINE:null
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:618)
... 9 more
{noformat}
Root cause is the bug in {{{}SimpleInMemoryKeyValueStorage{}}}, method
{{SimpleInMemoryKeyValueStorage#doGetValue}} throws NPE when tries to get
revision on the line {{if (lastVal.tombstone())}} because {{Value lastVal =
lastRevVals.get(key)}} is null.
*Upd*
Root cause was in incorrect usage of exact revision matching. Actually we don't
need such exact mapping at all.
was:
Reproducer on a feature branch ignite-14209 :
{code:java}
void testOneRebalance(@WorkDirectory Path workDir, TestInfo testInfo) throws
Exception {
TableDefinition schTbl1 = SchemaBuilders.tableBuilder("PUBLIC",
"tbl1").columns(
SchemaBuilders.column("key", ColumnType.INT64).build(),
SchemaBuilders.column("val",
ColumnType.INT32).asNullable(true).build()
).withPrimaryKey("key").build();
nodes.get(0).tableManager.createTable(
"PUBLIC.tbl1",
tblChanger -> SchemaConfigurationConverter.convert(schTbl1,
tblChanger)
.changeReplicas(1)
.changePartitions(1));
assertEquals(1,
nodes.get(0).clusterCfgMgr.configurationRegistry().getConfiguration(TablesConfiguration.KEY)
.tables().get("PUBLIC.TBL1").replicas().value());
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(3));
[jira] [Created] (IGNITE-17143) Review and rewrite rebalance document according to the last rebalance logic updates
Kirill Gusakov created IGNITE-17143: --- Summary: Review and rewrite rebalance document according to the last rebalance logic updates Key: IGNITE-17143 URL: https://issues.apache.org/jira/browse/IGNITE-17143 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Under IGNITE-14209 we made some rebalance protocol updates and it needs to update the document -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16088) Reuse Marshaller code in marshaller-common module
[ https://issues.apache.org/jira/browse/IGNITE-16088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-16088: --- Assignee: Pavel Tupitsyn > Reuse Marshaller code in marshaller-common module > - > > Key: IGNITE-16088 > URL: https://issues.apache.org/jira/browse/IGNITE-16088 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-14971 added *ignite-marshaller-common* module to reuse serialization > logic between the server and client parts. > This module duplicates some logic from *ignite-schema* module. > * Remove duplicated code from *ignite-schema* and reuse the logic from common > module. > * Extract other common bits where applicable (e.g. *AsmSerializerGenerator*) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16088) Reuse Marshaller code in marshaller-common module
[ https://issues.apache.org/jira/browse/IGNITE-16088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-16088: - Assignee: (was: Andrey Mashenkov) > Reuse Marshaller code in marshaller-common module > - > > Key: IGNITE-16088 > URL: https://issues.apache.org/jira/browse/IGNITE-16088 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-14971 added *ignite-marshaller-common* module to reuse serialization > logic between the server and client parts. > This module duplicates some logic from *ignite-schema* module. > * Remove duplicated code from *ignite-schema* and reuse the logic from common > module. > * Extract other common bits where applicable (e.g. *AsmSerializerGenerator*) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-15556) Drop SchemaBuilder public API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15556: - Assignee: (was: Andrey Mashenkov) > Drop SchemaBuilder public API. > -- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task >Reporter: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3, tech-debt > > Drop SchemaBuilders public API as schema manupulation will be available only > via SQL -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder public API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15556: -- Issue Type: Task (was: Improvement) > Drop SchemaBuilder public API. > -- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3 > > Drop SchemaBuilders public API as schema manupulation will be available only > via SQL -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder public API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15556: -- Description: Drop SchemaBuilders public API as schema manupulation will be available only via SQL (was: SchemaBuilders implements a public API interface and resides in the ignite-schema module. Public API implementation must be hidden from a user to avoid direct usage/instantiation, but we need a factory. This can be achieved in next ways 1. Use ServiceLoader for schema builders factory. This introduces implicit module dependency and a new factory interface/class. 2. Drop interfaces and make schema builders top-level public classes. As there is no need to have interfaces, for now, let's make the schema builder classes public.) > Drop SchemaBuilder public API. > -- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3 > > Drop SchemaBuilders public API as schema manupulation will be available only > via SQL -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder public API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15556: -- Labels: UX ignite-3 tech-debt (was: UX ignite-3) > Drop SchemaBuilder public API. > -- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3, tech-debt > > Drop SchemaBuilders public API as schema manupulation will be available only > via SQL -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder public API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15556: -- Summary: Drop SchemaBuilder public API. (was: Replace SchemaBuilder interfaces with class public classes.) > Drop SchemaBuilder public API. > -- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3 > > SchemaBuilders implements a public API interface and resides in the > ignite-schema module. > Public API implementation must be hidden from a user to avoid direct > usage/instantiation, but we need a factory. > This can be achieved in next ways > 1. Use ServiceLoader for schema builders factory. > This introduces implicit module dependency and a new factory interface/class. > 2. Drop interfaces and make schema builders top-level public classes. > As there is no need to have interfaces, for now, let's make the schema > builder classes public. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
[
https://issues.apache.org/jira/browse/IGNITE-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17139:
-
Epic Link: IGNITE-16851
Affects Version/s: 3.0.0-alpha5
> It is impossible to dynamically configure a RocksDB data region
> ---
>
> Key: IGNITE-17139
> URL: https://issues.apache.org/jira/browse/IGNITE-17139
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha5
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It is currently impossible to create a RocksDB data region (e.g. through the
> Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is
> that {{RocksDbStorageEngine}} is missing a configuration listener that will
> register new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16590) Sort out and merge Calcite tickets to Ignite 3.0 (step 5)
[ https://issues.apache.org/jira/browse/IGNITE-16590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552008#comment-17552008 ] Yury Gerzhedovich commented on IGNITE-16590: the ticket without fix version due to it is ambrela ticket > Sort out and merge Calcite tickets to Ignite 3.0 (step 5) > - > > Key: IGNITE-16590 > URL: https://issues.apache.org/jira/browse/IGNITE-16590 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases let's > create separate tickets with estimation and link them to IGNITE-15658 or > links to blocker ticket. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-14830) Introduce sorted index prototype
[ https://issues.apache.org/jira/browse/IGNITE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552005#comment-17552005 ] Yury Gerzhedovich commented on IGNITE-14830: the ticket without fix version due to is part of feature branch. > Introduce sorted index prototype > > > Key: IGNITE-14830 > URL: https://issues.apache.org/jira/browse/IGNITE-14830 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Labels: iep-74, ignite-3 > Time Spent: 11h > Remaining Estimate: 0h > > The goals of the sorted index prototype: > - introduce internal API for the sorted indexes; > - the implementation basic function of the IndexManager create/drop index for > the simple cases; > - the implementation basic function of the sorted index: put/remove/range scan > - basic SQL integration. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-14830) Introduce sorted index prototype
[ https://issues.apache.org/jira/browse/IGNITE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-14830: --- Fix Version/s: (was: 3.0.0-alpha5) > Introduce sorted index prototype > > > Key: IGNITE-14830 > URL: https://issues.apache.org/jira/browse/IGNITE-14830 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Labels: iep-74, ignite-3 > Time Spent: 11h > Remaining Estimate: 0h > > The goals of the sorted index prototype: > - introduce internal API for the sorted indexes; > - the implementation basic function of the IndexManager create/drop index for > the simple cases; > - the implementation basic function of the sorted index: put/remove/range scan > - basic SQL integration. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16590) Sort out and merge Calcite tickets to Ignite 3.0 (step 5)
[ https://issues.apache.org/jira/browse/IGNITE-16590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16590: --- Fix Version/s: (was: 3.0.0-alpha5) > Sort out and merge Calcite tickets to Ignite 3.0 (step 5) > - > > Key: IGNITE-16590 > URL: https://issues.apache.org/jira/browse/IGNITE-16590 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases let's > create separate tickets with estimation and link them to IGNITE-15658 or > links to blocker ticket. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17111) Remove the ability to set the lazy flag in SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-17111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551972#comment-17551972 ] Evgeny Stanilovsky commented on IGNITE-17111: - also do we have benchmarks for 'lazy' mode ? i suppose it usage is not a cost free. > Remove the ability to set the lazy flag in SqlFieldsQuery > - > > Key: IGNITE-17111 > URL: https://issues.apache.org/jira/browse/IGNITE-17111 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > > Remove the ability to set the lazy flag in SqlFieldsQuery. SqlFieldsQuery > must always be executed as lazy=true. > This property > (org.apache.igniteIgniteSystemProperties#IGNITE_SQL_FORCE_LAZY_RESULT_SET) > refers to the same functionality, but is not used in the code. -- This message was sent by Atlassian Jira (v8.20.7#820007)
