[jira] [Created] (IGNITE-17029) Implement Consistent Cut algorithm
Maksim Timonin created IGNITE-17029: --- Summary: Implement Consistent Cut algorithm Key: IGNITE-17029 URL: https://issues.apache.org/jira/browse/IGNITE-17029 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin Assignee: Maksim Timonin Consistent Cut is algorithm for finding Points In Time for Recovering (PITR). Such points must guarantee transactional consistency over whole cluster. See details in IEP: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16980) PageMemoryPartitionStorage#write() can leak page slots
[
https://issues.apache.org/jira/browse/IGNITE-16980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-16980:
-
Epic Link: IGNITE-16232
> PageMemoryPartitionStorage#write() can leak page slots
> --
>
> Key: IGNITE-16980
> URL: https://issues.apache.org/jira/browse/IGNITE-16980
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> {{public void write(DataRow row) throws StorageException {}}
> {{ try {}}
> {{ TableDataRow dataRow = wrap(row);}}
> {{ freeList.insertDataRow(dataRow);}}
> {{ tree.put(dataRow);}}
> {{ } catch (IgniteInternalCheckedException e) {}}
> {{ throw new StorageException("Error writing row", e);}}
> {{ }}}
> {{}}}
> This code always occupies a slot in a data page, even if the key was already
> put to the partition. So, if 2 puts with same key occur, one page slot is
> wasted.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17021) Move ignite-geospatial module to the Ignite extensoins
[ https://issues.apache.org/jira/browse/IGNITE-17021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17021: - Release Note: Moved geospatial to the Ignite Extensions project > Move ignite-geospatial module to the Ignite extensoins > -- > > Key: IGNITE-17021 > URL: https://issues.apache.org/jira/browse/IGNITE-17021 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite-geospatial must be moved to the Ignite Extensions since it is not > updated for a few years. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17021) Move ignite-geospatial module to the Ignite extensoins
[ https://issues.apache.org/jira/browse/IGNITE-17021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541569#comment-17541569 ] Maxim Muzafarov commented on IGNITE-17021: -- A new suite created for the extension: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Geospatial&branch_IgniteExtensions_Tests=%3Cdefault%3E&tab=buildTypeStatusDiv > Move ignite-geospatial module to the Ignite extensoins > -- > > Key: IGNITE-17021 > URL: https://issues.apache.org/jira/browse/IGNITE-17021 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite-geospatial must be moved to the Ignite Extensions since it is not > updated for a few years. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17021) Move ignite-geospatial module to the Ignite extensoins
[ https://issues.apache.org/jira/browse/IGNITE-17021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541570#comment-17541570 ] Maxim Muzafarov commented on IGNITE-17021: -- Merged to the master branch. > Move ignite-geospatial module to the Ignite extensoins > -- > > Key: IGNITE-17021 > URL: https://issues.apache.org/jira/browse/IGNITE-17021 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite-geospatial must be moved to the Ignite Extensions since it is not > updated for a few years. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17028) Docker image not available for apache ignite(v2.13.0) on s390x architecture.
Rishi created IGNITE-17028: -- Summary: Docker image not available for apache ignite(v2.13.0) on s390x architecture. Key: IGNITE-17028 URL: https://issues.apache.org/jira/browse/IGNITE-17028 Project: Ignite Issue Type: Bug Reporter: Rishi Fix For: 2.14 Hi there, I noticed that 2.13.0 version of Docker image for s390x architecture is not available on Dockerhub. Please let me know if there is something I can do at my end to help publish the images. We had this issue opened earlier to address similar issue for 2.12.0: https://issues.apache.org/jira/browse/IGNITE-16481 FYI: @[~vveider] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16936) Incorrect DML syntax error message contains sensitive information
[ https://issues.apache.org/jira/browse/IGNITE-16936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541466#comment-17541466 ] Luchnikov Alexander commented on IGNITE-16936: -- [~jooger] IGNITE-7001 fixed a similar issue, but on the Duplicate key during INSERT event. In my case, we break down at the request parsing phase and display everything that we tried to execute - Syntax error in SQL statement "INSERT TEST[*] (ID, VAL) VALUES (3, 'SENSITIVE_DATA') "; expected "INTO"; SQL statement: > Incorrect DML syntax error message contains sensitive information > - > > Key: IGNITE-16936 > URL: https://issues.apache.org/jira/browse/IGNITE-16936 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Major > Labels: ise > Attachments: > IGNITE-16936_Ignore_IGNITE_TO_STRING_INCLUDE_SENSITIVE_in_wrong_syntax_DML_error_message_-.patch > > > Incorrect DML syntax error message contains sensitive information. > Regardless of the value of IGNITE_TO_STRING_INCLUDE_SENSITIVE. > Reproducer > [^IGNITE-16936_Ignore_IGNITE_TO_STRING_INCLUDE_SENSITIVE_in_wrong_syntax_DML_error_message_-.patch] > show what SENSITIVE contains in message. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data, use int as the value. # Delete data by specifying in the DML operation, as a condition, an indexed value, without String.valueOf(intValue) The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. The result of all tests should be the same, specifically in this example (DML delete) - the number of entries in the cache, according to the result of each test, should be equal to zero. was: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data, use int as the value. # Delete data by specifying in the DML operation, as a condition, an indexed value, without String.valueOf(intValue) The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Description of the case, in some environment, the DML operation does not > delete all data (this DML delete operation is an example). To reproduce the > problem, you must: > # Create a table with a varchar field. > # Create an index on the given field. > # Fill the table with data, use int as the value. > # Delete data by specifying in the DML operation, as a condition, an indexed > value, without String.valueOf(intValue) > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. > The result of all tests should be the same, specifically in this example (DML > delete) - the number of entries in the cache, according to the result of each > test, should be equal to zero. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data, use int as the value. # Delete data by specifying in the DML operation, as a condition, an indexed value, without String.valueOf(intValue) The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. was: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data. # Delete data by specifying in the DML operation, as a condition, an indexed value. The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Description of the case, in some environment, the DML operation does not > delete all data (this DML delete operation is an example). To reproduce the > problem, you must: > # Create a table with a varchar field. > # Create an index on the given field. > # Fill the table with data, use int as the value. > # Delete data by specifying in the DML operation, as a condition, an indexed > value, without String.valueOf(intValue) > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data. # Delete data by specifying in the DML operation, as a condition, an indexed value. The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. was: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data. # Delete data by specifying in the DML operation, as a condition, an indexed value. The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Description of the case, in some environment, the DML operation does not > delete all data (this DML delete operation is an example). To reproduce the > problem, you must: > # Create a table with a varchar field. > # Create an index on the given field. > # Fill the table with data. > # Delete data by specifying in the DML operation, as a condition, an indexed > value. > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Description of the case, in some environment, the DML operation does not delete all data (this DML delete operation is an example). To reproduce the problem, you must: # Create a table with a varchar field. # Create an index on the given field. # Fill the table with data. # Delete data by specifying in the DML operation, as a condition, an indexed value. The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. was: Case descriptions, in some environment, The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Description of the case, in some environment, the DML operation does not > delete all data (this DML delete operation is an example). To reproduce the > problem, you must: > # Create a table with a varchar field. > # Create an index on the given field. > # Fill the table with data. > # Delete data by specifying in the DML operation, as a condition, an indexed > value. > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Case descriptions, in some environment, The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. was: Case descriptions, шт ыщьу The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Case descriptions, in some environment, > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Case descriptions, шт ыщьу The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. was: Case descriptions: # The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Case descriptions, шт ыщьу > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Case descriptions: # The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in indexOnAutocastOff() test. was: Case descriptions: # The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Case descriptions: > # > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in > indexOnAutocastOff() test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Description: Case descriptions: # The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior. was: Case descriptions: # The reproducer() shows this behavior. > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Case descriptions: > # > The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
Luchnikov Alexander created IGNITE-17027: Summary: Incorrect result of the DML delete operation, in some environment Key: IGNITE-17027 URL: https://issues.apache.org/jira/browse/IGNITE-17027 Project: Ignite Issue Type: Bug Reporter: Luchnikov Alexander Attachments: IndexSetArgsAndCastTest.patch Case descriptions: # The reproducer() shows this behavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment
[ https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17027: - Labels: ise (was: ) > Incorrect result of the DML delete operation, in some environment > -- > > Key: IGNITE-17027 > URL: https://issues.apache.org/jira/browse/IGNITE-17027 > Project: Ignite > Issue Type: Bug >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: IndexSetArgsAndCastTest.patch > > > Case descriptions: > # > The reproducer() shows this behavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17021) Move ignite-geospatial module to the Ignite extensoins
[
https://issues.apache.org/jira/browse/IGNITE-17021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541451#comment-17541451
]
Ignite TC Bot commented on IGNITE-17021:
{panel:title=Branch: [pull/10032/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Geospatial Indexing{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6585349]]
{panel}
{panel:title=Branch: [pull/10032/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=6583990&buildTypeId=IgniteTests24Java8_RunAll]
> Move ignite-geospatial module to the Ignite extensoins
> --
>
> Key: IGNITE-17021
> URL: https://issues.apache.org/jira/browse/IGNITE-17021
> Project: Ignite
> Issue Type: Task
> Components: extensions
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ignite-geospatial must be moved to the Ignite Extensions since it is not
> updated for a few years.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (IGNITE-14814) SQL statistics: drop statistics on cache destroy / DROP TABLE
[ https://issues.apache.org/jira/browse/IGNITE-14814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-14814. -- Resolution: Duplicate > SQL statistics: drop statistics on cache destroy / DROP TABLE > - > > Key: IGNITE-14814 > URL: https://issues.apache.org/jira/browse/IGNITE-14814 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Belyak >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.14 > > > Now we cannot drop statistics automatically on cache destroy. > It depends on GridCacheProcessor#stopCache destroy flag. It is false when the > all caches from a group are stopped. In this case group -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-14814) SQL statistics: drop statistics on cache destroy / DROP TABLE
[ https://issues.apache.org/jira/browse/IGNITE-14814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14814: - Fix Version/s: (was: 2.14) > SQL statistics: drop statistics on cache destroy / DROP TABLE > - > > Key: IGNITE-14814 > URL: https://issues.apache.org/jira/browse/IGNITE-14814 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Belyak >Assignee: Semyon Danilov >Priority: Major > > Now we cannot drop statistics automatically on cache destroy. > It depends on GridCacheProcessor#stopCache destroy flag. It is false when the > all caches from a group are stopped. In this case group -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (IGNITE-14814) SQL statistics: drop statistics on cache destroy / DROP TABLE
[ https://issues.apache.org/jira/browse/IGNITE-14814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reopened IGNITE-14814: -- Ignite Flags: (was: Docs Required,Release Notes Required) > SQL statistics: drop statistics on cache destroy / DROP TABLE > - > > Key: IGNITE-14814 > URL: https://issues.apache.org/jira/browse/IGNITE-14814 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Belyak >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.14 > > > Now we cannot drop statistics automatically on cache destroy. > It depends on GridCacheProcessor#stopCache destroy flag. It is false when the > all caches from a group are stopped. In this case group -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17017) [Native Persistence 3.0] Move "pageSize" to the common configuration
[ https://issues.apache.org/jira/browse/IGNITE-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17017: - Labels: ignite-3 (was: ) > [Native Persistence 3.0] Move "pageSize" to the common configuration > > > Key: IGNITE-17017 > URL: https://issues.apache.org/jira/browse/IGNITE-17017 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Move the *pageSize* into the common configuration for the *page-memory*, but > for this, at the beginning we need to implement a non-internal configuration > extension so that we can make a configuration for the *volatile* and the > *persistent* configuration of the *page-memory*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16992) Partial node in ItIgniteNodeRestartTest should join the CMG
[
https://issues.apache.org/jira/browse/IGNITE-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16992:
-
Labels: ignite-3 (was: )
> Partial node in ItIgniteNodeRestartTest should join the CMG
> ---
>
> Key: IGNITE-16992
> URL: https://issues.apache.org/jira/browse/IGNITE-16992
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> {{ItIgniteNodeRestartTest#testMetastorageStop}} test fails if the node,
> started in {{startPartialNode}}, executes {{cmgManager.joinFuture()}}. For
> some reason, it stops receiving Meta Storage revision updates after the Meta
> Storage node is restarted.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541434#comment-17541434
]
Taras Ledkov commented on IGNITE-14961:
---
[~vladsz83], according with SQL2003: 4.6.4 (Table 7) DATE + NUMERIC is not
standard behavior.
But the most popular DB engines support this syntax.
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Minor
> Labels: uncertain
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
> Tests:
> {{function/date/test_extract_edge_cases.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17022) Implement interceptors for Ignite Services
[
https://issues.apache.org/jira/browse/IGNITE-17022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17022:
--
Labels: iep-79 important ise (was: iep-79 important)
> Implement interceptors for Ignite Services
> --
>
> Key: IGNITE-17022
> URL: https://issues.apache.org/jira/browse/IGNITE-17022
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-79, important, ise
> Fix For: 2.14
>
>
> Currenlty, Ignite Services has a lack of support execution a custom
> middleware process before and after a service execution. This leads to a lot
> of boilerplate code.
> The IEP-79 describes a draft API of such a feature implementation:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334119
> However, we still need to consider additional crucial points of such API:
> - sync or async listeners/interceptors execution (some of processes may
> require to set and clear threadlocals);
> - an exception in the inteceptrod should or should not interrupt a service
> execution;
> - {{context}} may need to be accessible inside interceptors and services;
> Also we need to add description about what kind of the {{guarantees}} are
> provided by Ignite server node during a service execution. It may be
> necessary to consider the service-per-thread execution logic.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-15067) Add custom destination path to the snapshost API
[
https://issues.apache.org/jira/browse/IGNITE-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15067:
--
Labels: iep-43 ise (was: iep-43)
> Add custom destination path to the snapshost API
>
>
> Key: IGNITE-15067
> URL: https://issues.apache.org/jira/browse/IGNITE-15067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43, ise
>
> The default configuration path obtains from the IgniteConfiguration. However,
> in some circumstances, it is good to set this destination path at runtime.
> This path must be configured relatively in the node working directory and
> must be accessible from the security point of view.
> Proposed API:
> {code}
> public IgniteFuture createSnapshot(String name, Path locPath);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-17026) Add the 2.13 version to compatibility tests
[ https://issues.apache.org/jira/browse/IGNITE-17026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita reassigned IGNITE-17026: Assignee: Amelchev Nikita > Add the 2.13 version to compatibility tests > --- > > Key: IGNITE-17026 > URL: https://issues.apache.org/jira/browse/IGNITE-17026 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add the 2.13 version to compatibility tests -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16717) Implement node validation
[ https://issues.apache.org/jira/browse/IGNITE-16717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541427#comment-17541427 ] Alexander Lapin commented on IGNITE-16717: -- [~apolovtcev] LGTM from my side. > Implement node validation > - > > Key: IGNITE-16717 > URL: https://issues.apache.org/jira/browse/IGNITE-16717 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 6h 20m > Remaining Estimate: 0h > > When a node joins a cluster, it should be both self-validated and fully > validated on the CMG leader. This includes checking the protocol version, the > Ignite product version and the cluster tag. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[
https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-17025:
-
Description:
The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when
INLINE_SIZE increases when creating indexes on fixed length fields.The negative
point is that a place is reserved that does not carry any profit.
As a solution. When trying to build an index on a field with a fixed length
type, do not allow this. The value of INLINE_SIZE for such types is calculated
automatically. And display a WARN level message about it.
To see the size of index.bin, run the
{code:java}
du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
{code}
after running the reproducer.
was:
The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when
INLINE_SIZE increases when creating indexes on fixed length fields.The negative
point is that a place is reserved that does not carry any profit.
As a solution. When trying to build an index on a field with a fixed length
type, do not allow this. The value of INLINE_SIZE for such types is calculated
automatically. And display a WARN level message about it.
To see the size of index.bin, run the "du -sh IGNITE_HOME/db/node*/*INLINE*/* |
grep index.bin" after running the reproducer.
> Remove the ability to manually set INLINE_SIZE for types with a fixed length
>
>
> Key: IGNITE-17025
> URL: https://issues.apache.org/jira/browse/IGNITE-17025
> Project: Ignite
> Issue Type: Improvement
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
> Attachments: InlineIndexTest1.patch
>
>
> The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing
> when INLINE_SIZE increases when creating indexes on fixed length fields.The
> negative point is that a place is reserved that does not carry any profit.
> As a solution. When trying to build an index on a field with a fixed length
> type, do not allow this. The value of INLINE_SIZE for such types is
> calculated automatically. And display a WARN level message about it.
> To see the size of index.bin, run the
> {code:java}
> du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
> {code}
> after running the reproducer.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17026) Add the 2.13 version to compatibility tests
Amelchev Nikita created IGNITE-17026: Summary: Add the 2.13 version to compatibility tests Key: IGNITE-17026 URL: https://issues.apache.org/jira/browse/IGNITE-17026 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Add the 2.13 version to compatibility tests -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[
https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-17025:
-
Description:
The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when
INLINE_SIZE increases when creating indexes on fixed length fields.The negative
point is that a place is reserved that does not carry any profit.
As a solution. When trying to build an index on a field with a fixed length
type, do not allow this. The value of INLINE_SIZE for such types is calculated
automatically. And display a WARN level message about it.
To see the size of index.bin, run the
{code:java}
du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
{code}
after running the reproducer.
{code:java}
36K BIGINT_INLINE10/index.bin
320K BIGINT_INLINE100/index.bin
128K INT_INLINE10/index.bin
324K INT_INLINE100/index.bin
64K NUMBER_INLINE10/index.bin
64K NUMBER_INLINE100/index.bin
128K VARCHAR_INLINE10/index.bin
256K VARCHAR_INLINE100/index.bin
{code}
was:
The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when
INLINE_SIZE increases when creating indexes on fixed length fields.The negative
point is that a place is reserved that does not carry any profit.
As a solution. When trying to build an index on a field with a fixed length
type, do not allow this. The value of INLINE_SIZE for such types is calculated
automatically. And display a WARN level message about it.
To see the size of index.bin, run the
{code:java}
du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
{code}
after running the reproducer.
> Remove the ability to manually set INLINE_SIZE for types with a fixed length
>
>
> Key: IGNITE-17025
> URL: https://issues.apache.org/jira/browse/IGNITE-17025
> Project: Ignite
> Issue Type: Improvement
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
> Attachments: InlineIndexTest1.patch
>
>
> The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing
> when INLINE_SIZE increases when creating indexes on fixed length fields.The
> negative point is that a place is reserved that does not carry any profit.
> As a solution. When trying to build an index on a field with a fixed length
> type, do not allow this. The value of INLINE_SIZE for such types is
> calculated automatically. And display a WARN level message about it.
> To see the size of index.bin, run the
> {code:java}
> du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
> {code}
> after running the reproducer.
> {code:java}
> 36K BIGINT_INLINE10/index.bin
> 320K BIGINT_INLINE100/index.bin
> 128K INT_INLINE10/index.bin
> 324K INT_INLINE100/index.bin
> 64K NUMBER_INLINE10/index.bin
> 64K NUMBER_INLINE100/index.bin
> 128K VARCHAR_INLINE10/index.bin
> 256K VARCHAR_INLINE100/index.bin
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[ https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17025: - Labels: ise (was: ) > Remove the ability to manually set INLINE_SIZE for types with a fixed length > > > Key: IGNITE-17025 > URL: https://issues.apache.org/jira/browse/IGNITE-17025 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > Attachments: InlineIndexTest1.patch > > > The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing > when INLINE_SIZE increases when creating indexes on fixed length fields.The > negative point is that a place is reserved that does not carry any profit. > As a solution. When trying to build an index on a field with a fixed length > type, do not allow this. The value of INLINE_SIZE for such types is > calculated automatically. And display a WARN level message about it. > To see the size of index.bin, run the "du -sh IGNITE_HOME/db/node*/*INLINE*/* > | grep index.bin" after running the reproducer. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16877) C++ Thin: Implement ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541413#comment-17541413 ] Pavel Tupitsyn commented on IGNITE-16877: - [~isapego] looks good, thanks! > C++ Thin: Implement ScanQuery > - > > Key: IGNITE-16877 > URL: https://issues.apache.org/jira/browse/IGNITE-16877 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Need to add the ScanQuery API to C++ thin client: > * The ScanQuery must have a partition property: it may be used to do parallel > initial data load to improve performance. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[ https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17025: - Description: The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when INLINE_SIZE increases when creating indexes on fixed length fields.The negative point is that a place is reserved that does not carry any profit. As a solution. When trying to build an index on a field with a fixed length type, do not allow this. The value of INLINE_SIZE for such types is calculated automatically. And display a WARN level message about it. To see the size of index.bin, run the "du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin" after running the reproducer. was: The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when INLINE_SIZE increases when creating indexes on fixed length fields.The negative point is that a place is reserved that does not carry any profit. As a solution. When trying to build an index on a field with a fixed length type, do not allow this. The value of INLINE_SIZE for such types is calculated automatically. And display a WARN level message about it. > Remove the ability to manually set INLINE_SIZE for types with a fixed length > > > Key: IGNITE-17025 > URL: https://issues.apache.org/jira/browse/IGNITE-17025 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Attachments: InlineIndexTest1.patch > > > The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing > when INLINE_SIZE increases when creating indexes on fixed length fields.The > negative point is that a place is reserved that does not carry any profit. > As a solution. When trying to build an index on a field with a fixed length > type, do not allow this. The value of INLINE_SIZE for such types is > calculated automatically. And display a WARN level message about it. > To see the size of index.bin, run the "du -sh IGNITE_HOME/db/node*/*INLINE*/* > | grep index.bin" after running the reproducer. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[ https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17025: - Description: The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing when INLINE_SIZE increases when creating indexes on fixed length fields.The negative point is that a place is reserved that does not carry any profit. As a solution. When trying to build an index on a field with a fixed length type, do not allow this. The value of INLINE_SIZE for such types is calculated automatically. And display a WARN level message about it. was:As a solution. When trying to build an index on a field with a fixed length type, do not allow this. The value of INLINE_SIZE for such types is calculated automatically. And display a WARN level message about it. > Remove the ability to manually set INLINE_SIZE for types with a fixed length > > > Key: IGNITE-17025 > URL: https://issues.apache.org/jira/browse/IGNITE-17025 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Attachments: InlineIndexTest1.patch > > > The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing > when INLINE_SIZE increases when creating indexes on fixed length fields.The > negative point is that a place is reserved that does not carry any profit. > As a solution. When trying to build an index on a field with a fixed length > type, do not allow this. The value of INLINE_SIZE for such types is > calculated automatically. And display a WARN level message about it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[ https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17025: - Description: As a solution. When trying to build an index on a field with a fixed length type, do not allow this. The value of INLINE_SIZE for such types is calculated automatically. And display a WARN level message about it. > Remove the ability to manually set INLINE_SIZE for types with a fixed length > > > Key: IGNITE-17025 > URL: https://issues.apache.org/jira/browse/IGNITE-17025 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Attachments: InlineIndexTest1.patch > > > As a solution. When trying to build an index on a field with a fixed length > type, do not allow this. The value of INLINE_SIZE for such types is > calculated automatically. And display a WARN level message about it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[ https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander updated IGNITE-17025: - Attachment: InlineIndexTest1.patch > Remove the ability to manually set INLINE_SIZE for types with a fixed length > > > Key: IGNITE-17025 > URL: https://issues.apache.org/jira/browse/IGNITE-17025 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Attachments: InlineIndexTest1.patch > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
Luchnikov Alexander created IGNITE-17025: Summary: Remove the ability to manually set INLINE_SIZE for types with a fixed length Key: IGNITE-17025 URL: https://issues.apache.org/jira/browse/IGNITE-17025 Project: Ignite Issue Type: Improvement Reporter: Luchnikov Alexander -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-15067) Add custom destination path to the snapshost API
[
https://issues.apache.org/jira/browse/IGNITE-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-15067:
-
Assignee: Pavel Pereslegin (was: Maxim Muzafarov)
> Add custom destination path to the snapshost API
>
>
> Key: IGNITE-15067
> URL: https://issues.apache.org/jira/browse/IGNITE-15067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43
>
> The default configuration path obtains from the IgniteConfiguration. However,
> in some circumstances, it is good to set this destination path at runtime.
> This path must be configured relatively in the node working directory and
> must be accessible from the security point of view.
> Proposed API:
> {code}
> public IgniteFuture createSnapshot(String name, Path locPath);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17005) Implement metrics for a snapshot create operation
[ https://issues.apache.org/jira/browse/IGNITE-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17005: - Fix Version/s: 2.14 > Implement metrics for a snapshot create operation > - > > Key: IGNITE-17005 > URL: https://issues.apache.org/jira/browse/IGNITE-17005 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.14 > > > Snapshot create operation can take a long time, we must be able to track its > progress using metrics. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17005) Implement metrics for a snapshot create operation
[ https://issues.apache.org/jira/browse/IGNITE-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17005: - Labels: ise (was: ) > Implement metrics for a snapshot create operation > - > > Key: IGNITE-17005 > URL: https://issues.apache.org/jira/browse/IGNITE-17005 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Labels: ise > Fix For: 2.14 > > > Snapshot create operation can take a long time, we must be able to track its > progress using metrics. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16877) C++ Thin: Implement ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541401#comment-17541401 ] Igor Sapego commented on IGNITE-16877: -- [~ptupitsyn] fixed. Can you take another look? > C++ Thin: Implement ScanQuery > - > > Key: IGNITE-16877 > URL: https://issues.apache.org/jira/browse/IGNITE-16877 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Need to add the ScanQuery API to C++ thin client: > * The ScanQuery must have a partition property: it may be used to do parallel > initial data load to improve performance. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16888) Update Ignite dependency: lz4
[
https://issues.apache.org/jira/browse/IGNITE-16888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541390#comment-17541390
]
Ignite TC Bot commented on IGNITE-16888:
{panel:title=Branch: [pull/10020/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}~[DEPRECATED] Hibernate 5.3{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6441328]]
{color:#d04437}~[DEPRECATED] Hibernate 5.1{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6441330]]
{color:#d04437}~[DEPRECATED] Hibernate 4.2{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6441332]]
{panel}
{panel:title=Branch: [pull/10020/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6434270&buildTypeId=IgniteTests24Java8_RunAll]
> Update Ignite dependency: lz4
> -
>
> Key: IGNITE-16888
> URL: https://issues.apache.org/jira/browse/IGNITE-16888
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update lz4 dependency 1.5.0 to 1.8.0
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16856) Sql. Ability to create table without specifying PK
[
https://issues.apache.org/jira/browse/IGNITE-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541385#comment-17541385
]
Taras Ledkov commented on IGNITE-16856:
---
[~korlov], please create & link issues for UUID type support and RexNode to
generate randomUuid.
{{TableDescriptorImpl#newColumnDefaultValue}} kooks like the proper place to
generate default value. But we have to do it at the
{{IgniteTableImpl#insertTuple}} because RexNode to generate random UUID is not
implemented.
> Sql. Ability to create table without specifying PK
> --
>
> Key: IGNITE-16856
> URL: https://issues.apache.org/jira/browse/IGNITE-16856
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> Despite a keyless use case currently is not supported by Ignite-3, SQL
> standard allows to create such tables, and many external tests (TCP-H for
> instance) are taking advantage of this.
> To make it easier to adopt such a tests, let's provide a special mode for
> Ignite, where implicit PK will be created in case of lack explicit one.
> Key points to consider:
> * This mode considered for test purpose only, hence the implementation
> should be as less invasive as possible.
> * An implicit key column should not be returned by {{SELECT *}} queries. It
> may be accessed by its name though.
> * Type of this column doesn't matter, but the range of possible values
> should be big enough to support billiones of unique values.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16877) C++ Thin: Implement ScanQuery
[
https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541375#comment-17541375
]
Ignite TC Bot commented on IGNITE-16877:
{panel:title=Branch: [pull/10033/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10033/head] Base: [master] : New Tests
(1072)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
1060|https://ci.ignite.apache.org/viewLog.html?buildId=6585097]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 1049 new tests
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6585095]]
* {color:#013220}IgniteThinClientTest: ScanQueryBasicTestSuite:
ScanQueryDefaults - PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryBasicTestSuite: ScanQuerySetGet
- PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryTestSuite: TestScanQuery -
PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryTestSuite:
TestScanQueryPartitioned - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6585096]]
* {color:#013220}IgniteThinClientTest: ScanQueryBasicTestSuite:
ScanQueryDefaults - PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryBasicTestSuite: ScanQuerySetGet
- PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryTestSuite: TestScanQuery -
PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryTestSuite:
TestScanQueryPartitioned - PASSED{color}
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6585098]]
* {color:#013220}IgniteThinClientTest: ScanQueryBasicTestSuite:
ScanQueryDefaults - PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryBasicTestSuite: ScanQuerySetGet
- PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryTestSuite: TestScanQuery -
PASSED{color}
* {color:#013220}IgniteThinClientTest: ScanQueryTestSuite:
TestScanQueryPartitioned - PASSED{color}
{panel}
[TeamCity *-> Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6585100&buildTypeId=IgniteTests24Java8_RunCpp]
> C++ Thin: Implement ScanQuery
> -
>
> Key: IGNITE-16877
> URL: https://issues.apache.org/jira/browse/IGNITE-16877
> Project: Ignite
> Issue Type: New Feature
> Components: platforms, thin client
>Affects Versions: 2.12
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Need to add the ScanQuery API to C++ thin client:
> * The ScanQuery must have a partition property: it may be used to do parallel
> initial data load to improve performance.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16877) C++ Thin: Implement ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541353#comment-17541353 ] Pavel Tupitsyn commented on IGNITE-16877: - [~isapego] overall looks good to me. Added a few minor comments on GitHub. > C++ Thin: Implement ScanQuery > - > > Key: IGNITE-16877 > URL: https://issues.apache.org/jira/browse/IGNITE-16877 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to add the ScanQuery API to C++ thin client: > * The ScanQuery must have a partition property: it may be used to do parallel > initial data load to improve performance. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17024) C++: Fix TestLongEventsProcessingDisconnect test
[ https://issues.apache.org/jira/browse/IGNITE-17024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-17024: - Description: Fix specified test. It fails almost every time > C++: Fix TestLongEventsProcessingDisconnect test > > > Key: IGNITE-17024 > URL: https://issues.apache.org/jira/browse/IGNITE-17024 > Project: Ignite > Issue Type: Bug >Reporter: Igor Sapego >Priority: Major > > Fix specified test. It fails almost every time -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17024) C++: Fix TestLongEventsProcessingDisconnect test
Igor Sapego created IGNITE-17024: Summary: C++: Fix TestLongEventsProcessingDisconnect test Key: IGNITE-17024 URL: https://issues.apache.org/jira/browse/IGNITE-17024 Project: Ignite Issue Type: Bug Reporter: Igor Sapego -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15241) Ignite H2 Security Vulnerabilities
[
https://issues.apache.org/jira/browse/IGNITE-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-15241:
--
Affects Version/s: 2.13
(was: 2.10)
> Ignite H2 Security Vulnerabilities
> --
>
> Key: IGNITE-15241
> URL: https://issues.apache.org/jira/browse/IGNITE-15241
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Labels: cggg
> Original Estimate: 80h
> Remaining Estimate: 80h
>
> Upgrade H2 dependency of the ignite-indexing module to the latest version
> 1.4.200.
> Apache Ignite SQL (module {{ignite-indexing}}) depends on H2 database version
> 1.4.197, which has these two [security
> vulnerabilities|https://www.cvedetails.com/vulnerability-list/vendor_id-17893/product_id-45580/year-2018/H2database-H2.html]
> [CVE-2018-14335|https://www.cvedetails.com/cve/CVE-2018-14335/] is regarded
> as a critical vulnerability by our analyzer (Black Duck SCA) and makes it
> impossible to use Ignite SQL due to security policies. We realize this
> vulnerability is probably not even applicable to the H2 in Ignite since there
> is no H2 database or H2 backups in Ignite. Still the security policies are
> very formal and do not allow that anyway.
> We believe there are lots of other enterprises having the same issue. For
> example, there is another issue IGNITE-14381 referencing the same problem.
> The latest H2 1.4.200 has no vulnerabilities.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Reopened] (IGNITE-15241) Ignite H2 Security Vulnerabilities
[
https://issues.apache.org/jira/browse/IGNITE-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin reopened IGNITE-15241:
---
I guess the issue was closed by mistake. I do not see how the H2 pull request
mentioned in the previous comment addresses this problem
> Ignite H2 Security Vulnerabilities
> --
>
> Key: IGNITE-15241
> URL: https://issues.apache.org/jira/browse/IGNITE-15241
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Labels: cggg
> Original Estimate: 80h
> Remaining Estimate: 80h
>
> Upgrade H2 dependency of the ignite-indexing module to the latest version
> 1.4.200.
> Apache Ignite SQL (module {{ignite-indexing}}) depends on H2 database version
> 1.4.197, which has these two [security
> vulnerabilities|https://www.cvedetails.com/vulnerability-list/vendor_id-17893/product_id-45580/year-2018/H2database-H2.html]
> [CVE-2018-14335|https://www.cvedetails.com/cve/CVE-2018-14335/] is regarded
> as a critical vulnerability by our analyzer (Black Duck SCA) and makes it
> impossible to use Ignite SQL due to security policies. We realize this
> vulnerability is probably not even applicable to the H2 in Ignite since there
> is no H2 database or H2 backups in Ignite. Still the security policies are
> very formal and do not allow that anyway.
> We believe there are lots of other enterprises having the same issue. For
> example, there is another issue IGNITE-14381 referencing the same problem.
> The latest H2 1.4.200 has no vulnerabilities.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
