[jira] [Closed] (IGNITE-8591) SQL: Sort links on index pages in physical page order before row access
[ https://issues.apache.org/jira/browse/IGNITE-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-8591. --- > SQL: Sort links on index pages in physical page order before row access > --- > > Key: IGNITE-8591 > URL: https://issues.apache.org/jira/browse/IGNITE-8591 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > > When index page match condition, we eagerly read all matched data rows. This > leads to a number of random disk reads.as Ignite use heap-organized storage. > We can pre-sort all matched row links in accordance to their physical > location, and then read them in batch. This will give us two important > advantages: > 1) Data reads will be more sequential, this is especially important for HDDs > 2) This could decrease number of page reads in case of dense data placement, > because there will be less evictions. > In future we should expand this optimization to several index pages in the > same way it is done in major databases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7681) SQL COPY: local performance improvements
[ https://issues.apache.org/jira/browse/IGNITE-7681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7681. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: local performance improvements > > > Key: IGNITE-7681 > URL: https://issues.apache.org/jira/browse/IGNITE-7681 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4, 2.5 >Reporter: Kirill Shirokov >Priority: Major > Attachments: ignite-7681-cache-putall-processor.diff, > ignite-7681-perf-test.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7602) SQL COPY: add tests for file reading and JDBC connection failures
[ https://issues.apache.org/jira/browse/IGNITE-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7602. --- > SQL COPY: add tests for file reading and JDBC connection failures > - > > Key: IGNITE-7602 > URL: https://issues.apache.org/jira/browse/IGNITE-7602 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7605) SQL COPY: add more SQL parser tests for positive scenarios
[ https://issues.apache.org/jira/browse/IGNITE-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7605. --- > SQL COPY: add more SQL parser tests for positive scenarios > -- > > Key: IGNITE-7605 > URL: https://issues.apache.org/jira/browse/IGNITE-7605 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7661) SQL COPY: provide more tests for national Unicode characters (including surrogates and 0x10000+ range)
[ https://issues.apache.org/jira/browse/IGNITE-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7661. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: provide more tests for national Unicode characters (including > surrogates and 0x1+ range) > -- > > Key: IGNITE-7661 > URL: https://issues.apache.org/jira/browse/IGNITE-7661 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.5 >Reporter: Kirill Shirokov >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6903) Implement new JMX metrics for Indexing
[ https://issues.apache.org/jira/browse/IGNITE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6903. --- > Implement new JMX metrics for Indexing > -- > > Key: IGNITE-6903 > URL: https://issues.apache.org/jira/browse/IGNITE-6903 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Anton Vinogradov >Priority: Critical > Labels: iep-6, important > Fix For: 2.8 > > > These additional metrics and methods should be implemented: > - Space occupied by indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7724) SQL COPY: network performance improvements
[ https://issues.apache.org/jira/browse/IGNITE-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7724. --- > SQL COPY: network performance improvements > -- > > Key: IGNITE-7724 > URL: https://issues.apache.org/jira/browse/IGNITE-7724 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Kirill Shirokov >Assignee: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11323) Reduce boilerplate "System.setProperty" code in tests
[
https://issues.apache.org/jira/browse/IGNITE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11323:
---
Description:
There are many examples in tests where some property gets new value in
"beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets its
previous value in "afterTestsStopped"/"afterTest"/"finally block of test
method". This approach leads to excessive code that can be avoided.
I suggest implementing annotation "WithSystemProperty" (name is the subject to
discussion) that will allow us to write this:
{code:java}
@Test
@WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value =
"true")
public void testSkipCheckConsistencyFlagEnabled() throws Exception {
...
}
{code}
instead of this:
{code:java}
@Test
public void testSkipCheckConsistencyFlagEnabled() throws Exception {
String backup =
System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
try {
...
}
finally {
if (backup != null)
System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
backup);
else
System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
}
}
{code}
There also has to be ability to use this annotation on test class so new value
of system properties will be used in all of its test methods.
was:
There are many examples in tests where some property gets new value in
"beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets its
previous value in "afterTestsStopped"/"afterTest"/"finally block of test
method". This approach leads to excessive code that can be avoided.
I suggest implementing annotation "WithSystemProperty" (name is the subject to
discussion) that will allow us to write this:
{code:java}
@Test
@WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value =
"true")
public void testSkipCheckConsistencyFlagEnabled() throws Exception {
...
}
{code}
instead of this:
{code:java}
@Test
public void testSkipCheckConsistencyFlagEnabled() throws Exception {
String backup =
System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
try {
...
}
finally {
if (backup != null)
System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
backup);
else
System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
}
}
{code}
There's also has to be ability to use this annotation on test class so new
value of system properties will be used in all of its test methods.
> Reduce boilerplate "System.setProperty" code in tests
> -
>
> Key: IGNITE-11323
> URL: https://issues.apache.org/jira/browse/IGNITE-11323
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>
> There are many examples in tests where some property gets new value in
> "beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets
> its previous value in "afterTestsStopped"/"afterTest"/"finally block of test
> method". This approach leads to excessive code that can be avoided.
> I suggest implementing annotation "WithSystemProperty" (name is the subject
> to discussion) that will allow us to write this:
> {code:java}
> @Test
> @WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value
> = "true")
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> ...
> }
> {code}
> instead of this:
> {code:java}
> @Test
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> String backup =
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
> try {
> ...
> }
> finally {
> if (backup != null)
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
> backup);
> else
> System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
> }
> }
> {code}
>
> There also has to be ability to use this annotation on test class so new
> value of system properties will be used in all of its test methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7605) SQL COPY: add more SQL parser tests for positive scenarios
[ https://issues.apache.org/jira/browse/IGNITE-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7605. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: add more SQL parser tests for positive scenarios > -- > > Key: IGNITE-7605 > URL: https://issues.apache.org/jira/browse/IGNITE-7605 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7661) SQL COPY: provide more tests for national Unicode characters (including surrogates and 0x10000+ range)
[ https://issues.apache.org/jira/browse/IGNITE-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7661. --- > SQL COPY: provide more tests for national Unicode characters (including > surrogates and 0x1+ range) > -- > > Key: IGNITE-7661 > URL: https://issues.apache.org/jira/browse/IGNITE-7661 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.5 >Reporter: Kirill Shirokov >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7601) SQL COPY: add tests for implicit columns (_key, _val, _ver)
[ https://issues.apache.org/jira/browse/IGNITE-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7601. --- > SQL COPY: add tests for implicit columns (_key, _val, _ver) > --- > > Key: IGNITE-7601 > URL: https://issues.apache.org/jira/browse/IGNITE-7601 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7602) SQL COPY: add tests for file reading and JDBC connection failures
[ https://issues.apache.org/jira/browse/IGNITE-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7602. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: add tests for file reading and JDBC connection failures > - > > Key: IGNITE-7602 > URL: https://issues.apache.org/jira/browse/IGNITE-7602 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11019) SQL: explain plan of a simple query contains merge table
[
https://issues.apache.org/jira/browse/IGNITE-11019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-11019:
-
Issue Type: Improvement (was: Bug)
> SQL: explain plan of a simple query contains merge table
>
>
> Key: IGNITE-11019
> URL: https://issues.apache.org/jira/browse/IGNITE-11019
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> In case of simple* query like following "select * from Organization org where
> org._KEY = 1 or org._KEY = 2" explain plan will contain merge table despite
> the fact that it's skipped within regular query flow.
> {code:java|title=GridReduceQueryExecutor#query}
> final boolean skipMergeTbl = !qry.explain() && qry.skipMergeTable()
> {code}
> Explain plan output:
> : [SELECT
> ORG__Z0.NAME AS __C0_0,
> ORG__Z0.DEBTCAPITAL AS __C0_1,
> ORG__Z0.ID AS __C0_2
> FROM "orgBetweenTest".ORGANIZATION ORG__Z0
> /* "orgBetweenTest"."_key_PK": _KEY IN(1, 2) */
> WHERE ORG__Z0._KEY IN(1, 2)]
> : [SELECT
> __C0_0 AS NAME,
> __C0_1 AS DEBTCAPITAL,
> __C0_2 AS ID
> FROM PUBLIC.__T0
> /* "orgBetweenTest"."merge_scan" */]
> *simple query by means of GridSqlQuery#simpleQuery
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9771) Indirect SQL queries are failing
[ https://issues.apache.org/jira/browse/IGNITE-9771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-9771. --- > Indirect SQL queries are failing > > > Key: IGNITE-9771 > URL: https://issues.apache.org/jira/browse/IGNITE-9771 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > Attachments: sgrimstad_IGNITE_9771_implementation_.patch > > > Attempt to sql query (not sql fields query ) another cache's type leads to > exception: > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > find SQL table for type: ... > IgniteH2Indexing#queryDistributedSql in the beginning of the method logic > there is check of schemaName, cacheName and type. First two parameters passed > belong to called cache while third belongs to target cache. This combination > leads to the exception mentioned. > # Create tests to reproduce the situation > # Fix problem > # Enable commented out tests with 'todo' and this ticket number reference -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6677) Collect QueryDetailMetrics for cache-less SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6677. - Resolution: Duplicate Fixed in IGNITE-10347. > Collect QueryDetailMetrics for cache-less SQL queries > - > > Key: IGNITE-6677 > URL: https://issues.apache.org/jira/browse/IGNITE-6677 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.2 >Reporter: Alexey Kuznetsov >Priority: Blocker > Labels: iep-29 > Fix For: 2.8 > > Attachments: sgrimstad_IGNITE_6677_implementation_.patch > > > We have logic that collect query history per caches. > We need: > # Add history size param on IgniteConfiguration > # Implement logic that will collect history for SQL queries executed directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6677) Collect QueryDetailMetrics for cache-less SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6677: Labels: (was: iep-29) > Collect QueryDetailMetrics for cache-less SQL queries > - > > Key: IGNITE-6677 > URL: https://issues.apache.org/jira/browse/IGNITE-6677 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.2 >Reporter: Alexey Kuznetsov >Priority: Blocker > Fix For: 2.8 > > Attachments: sgrimstad_IGNITE_6677_implementation_.patch > > > We have logic that collect query history per caches. > We need: > # Add history size param on IgniteConfiguration > # Implement logic that will collect history for SQL queries executed directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7554) SQL COPY: consider providing support for the command in batch mode
[ https://issues.apache.org/jira/browse/IGNITE-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7554. --- > SQL COPY: consider providing support for the command in batch mode > -- > > Key: IGNITE-7554 > URL: https://issues.apache.org/jira/browse/IGNITE-7554 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > > Currently SQL COPY command rejects to execute in JDBC batch mode (via > java.sql.Statement.addBatch() + executeBatch()). > If we want COPY to be executed in batch mode we need to implement it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7546) SQL COPY command: implement CSV header row parsing
[
https://issues.apache.org/jira/browse/IGNITE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7546.
---
> SQL COPY command: implement CSV header row parsing
> --
>
> Key: IGNITE-7546
> URL: https://issues.apache.org/jira/browse/IGNITE-7546
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>
> Implement optional reading of CSV format header row and matching it to column
> numbers.
> So, there are the following options:
> * just skip the header row (or arbitrary number of rows)
> * match the fields in the header row to the query entity columns and map them
> to the column list
> A possible syntax for this option might look like this:
> {noformat}
> COPY
> ...
> [(MATCH | SKIP) HEADER]
> {noformat}
> When implementing this feature please keep in mind that we might have an
> option for skipping user-specified number of header lines / left columns and
> importing only user-specified number of lines and columns.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7372) Implement escape sequences handling in internal SQL parser
[ https://issues.apache.org/jira/browse/IGNITE-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7372. --- > Implement escape sequences handling in internal SQL parser > -- > > Key: IGNITE-7372 > URL: https://issues.apache.org/jira/browse/IGNITE-7372 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Kirill Shirokov >Priority: Minor > > Implement escape sequences handling inside quoted literals. > The initial implementation is pruned from IGNITE-6861 and put into this > feature branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7542) SQL COPY command: implement multipliers (e.g., 'K' for kilo-, 'M' for mega-) in numbers
[
https://issues.apache.org/jira/browse/IGNITE-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7542.
-
Resolution: Won't Fix
Not relevant for now.
> SQL COPY command: implement multipliers (e.g., 'K' for kilo-, 'M' for mega-)
> in numbers
> ---
>
> Key: IGNITE-7542
> URL: https://issues.apache.org/jira/browse/IGNITE-7542
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Kirill Shirokov
>Priority: Minor
>
> Multipliers can be important for several options, such as batch size.
> The syntax could be:
> {noformat}
> COPY
> ...
> BATCH_SIZE 1.5M
> {noformat}
> Such number can have a decimal point and an optional multiplier:
> K: 1024
> M: 1024 * 1024
> ...and so on for giga-, tera-, and peta-
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7738) Allow 'multiple statements' in thin JDBC streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7738. --- > Allow 'multiple statements' in thin JDBC streaming mode > --- > > Key: IGNITE-7738 > URL: https://issues.apache.org/jira/browse/IGNITE-7738 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Priority: Major > > We need to update thin JDBC protocol to let user run multiple statements via > Statement.execute(String) when connection is in streamed mode. Currently in > streaming mode the server always receives all SQL in batches and its batch > processing logic does not allow multiple statements altogether. If we're able > to recognize initial nature of the statement, we'll be able to act > appropriately, and for this to be possible additional information must be > passed with each query in the batch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7738) Allow 'multiple statements' in thin JDBC streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7738: Component/s: (was: sql) jdbc > Allow 'multiple statements' in thin JDBC streaming mode > --- > > Key: IGNITE-7738 > URL: https://issues.apache.org/jira/browse/IGNITE-7738 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Alexander Paschenko >Priority: Major > > We need to update thin JDBC protocol to let user run multiple statements via > Statement.execute(String) when connection is in streamed mode. Currently in > streaming mode the server always receives all SQL in batches and its batch > processing logic does not allow multiple statements altogether. If we're able > to recognize initial nature of the statement, we'll be able to act > appropriately, and for this to be possible additional information must be > passed with each query in the batch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7549) SQL COPY: implement file transfer compression
[
https://issues.apache.org/jira/browse/IGNITE-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7549.
---
> SQL COPY: implement file transfer compression
> -
>
> Key: IGNITE-7549
> URL: https://issues.apache.org/jira/browse/IGNITE-7549
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>
> We can gain huge improvement in text file transfer times from client to
> server by using compression. User should have a possibility to enable or
> disable compression using a parameter of COPY command:
> {noformat}
> COPY
> ...
> [COMPRESS "codec-name" [codec options]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7553) SQL COPY: provide support for the command in org.apache.ignite.internal.jdbc2 driver
[ https://issues.apache.org/jira/browse/IGNITE-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7553. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: provide support for the command in org.apache.ignite.internal.jdbc2 > driver > > > Key: IGNITE-7553 > URL: https://issues.apache.org/jira/browse/IGNITE-7553 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Minor > > Currently COPY command is supported only in thin JDBC driver. It needs to be > supported in other JDBC driver implementations as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6996) Smarter handling of id fields in SQL values
[
https://issues.apache.org/jira/browse/IGNITE-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6996.
-
Resolution: Won't Fix
Not relevant at the moment.
> Smarter handling of id fields in SQL values
> ---
>
> Key: IGNITE-6996
> URL: https://issues.apache.org/jira/browse/IGNITE-6996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
>
> Consider such case:
> User wants to have a composite value (many value fields in {{QueryEntity}})
> with one field associated with value's id (most likely matching cache key
> too).
> Currently in order to insert such an object we will have to do something like
> {{INSERT INTO Person(_key, id, name) values(1, 1, 'John')}}
> And there's no way to avoid such a redundant repeat of the same value.
> Suggested approach: I believe that we should specifically handle the case
> when user specifies {{keyFieldName}} in configuration and specified field is
> field of the value.
> In such case, we could just do {{INSERT INTO Person(id, name) values(1,
> 'John')}} and derive {{_key}} value from {{id}} column. (And vice versa.)
> At a glance, this also will require following tweaks:
> - forbid performing SQL {{UPDATE}} on such column ({{id}} in above example);
> - on an {{INSERT}}, check that {{_key}} and {{id}} values are the same, if
> both specified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7541) SQL COPY command: implement backend switching option
[
https://issues.apache.org/jira/browse/IGNITE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7541.
---
> SQL COPY command: implement backend switching option
>
>
> Key: IGNITE-7541
> URL: https://issues.apache.org/jira/browse/IGNITE-7541
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Kirill Shirokov
>Priority: Major
>
> When we load data using COPY command we can add key/value pairs to the cache
> using different ways:
> * Directly calling cache.putAll()
> * Loading data via DataStreamer
> * etc.
> Every backend has its pros and cons. For example, the streamer is fast and
> asynchronous, although it cannot replace value and cannot provide any
> statistics -- such as number of added records. The direct interface is slow
> and synchronous, but provides us with an ability to either replace or skip
> the records with the same key and respond to the user with full statistics.
> There shall be an option in the SQL command to switch to particular backend.
> For example:
> {noformat}
> COPY
> FROM 'file'
> ...
> [BACKEND (DIRECT | STREAMER)]
> We might have more backends in the future.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5983) REST: Memory policy metrics should be available via REST.
[ https://issues.apache.org/jira/browse/IGNITE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768405#comment-16768405 ] Andrew Mashenkov commented on IGNITE-5983: -- [~roman_s], yes, now look good. I've just merged your PR this with latest master and re-run TC. > REST: Memory policy metrics should be available via REST. > - > > Key: IGNITE-5983 > URL: https://issues.apache.org/jira/browse/IGNITE-5983 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > For now it is possible to get some of cache metrics via REST, but not memory > metrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8692) MVCC TX: Always persistent TxLog
[ https://issues.apache.org/jira/browse/IGNITE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8692: Component/s: (was: sql) > MVCC TX: Always persistent TxLog > > > Key: IGNITE-8692 > URL: https://issues.apache.org/jira/browse/IGNITE-8692 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > > Currently TxLog may be overflowed in case a long running Tx prevents > "vacuuming". > It can be solved by enabling persistence for TxLog data region by default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8974) MVCC TX: Vacuum cleanup version obtaining optimization.
[ https://issues.apache.org/jira/browse/IGNITE-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8974: Component/s: (was: sql) > MVCC TX: Vacuum cleanup version obtaining optimization. > --- > > Key: IGNITE-8974 > URL: https://issues.apache.org/jira/browse/IGNITE-8974 > Project: Ignite > Issue Type: Improvement > Components: cache, mvcc >Reporter: Roman Kondakov >Priority: Major > > At the moment vacuum process obtains cleanup version as the same way as > transactions do. It implies some unnecessary complications and even minor > performance drop due to calculation entire tx snapshot instead of just a > cleanup version number or sending unnsecessary tx end acks back to the > coordinator. Possible solutions are: > * Local caching cleanup version from the last obtained tx snapshot and use > it in vacuum process. But in this way not all outdated versions could be > cleaned (i.e. keys updated by this last tx). > * Implement a special method for calculating cleanup version on the > coordinator site and Request and Response messages for vacuum runned on > non-coordinator site. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7998) SQL: Improve MVCC vacuum performance by iterating over data pages instead of cache tree.
[ https://issues.apache.org/jira/browse/IGNITE-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7998: Component/s: (was: sql) > SQL: Improve MVCC vacuum performance by iterating over data pages instead of > cache tree. > - > > Key: IGNITE-7998 > URL: https://issues.apache.org/jira/browse/IGNITE-7998 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Roman Kondakov >Priority: Major > > At the moment vacuum process uses cache trees to find outdated (dead) entries > and cache and index trees to cleanup them. It is not efficient due to several > reasons. For example, we should lock a datapage for each cache tree entry to > find out if entry is dead. > We can consider a direct iteration over datapages as a possible improvement > of the vacuum process. Data page iteration prototype demonstrated 5-10 times > time improvement over the tree iteration. > At first stage we need to implement direct datapages iteration only for > collecting dead entries links. > At the second stage we need to consider removing links to dead entries from > index pages directly. In other words, we need to efficiently remove batches > of dead links from indexes without traversing cache and index tree one dead > link by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8609) SQL: Get rid of syncronization in mvcc processor.
[ https://issues.apache.org/jira/browse/IGNITE-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8609: Component/s: (was: sql) > SQL: Get rid of syncronization in mvcc processor. > - > > Key: IGNITE-8609 > URL: https://issues.apache.org/jira/browse/IGNITE-8609 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Pavel Kuznetsov >Assignee: Igor Seliverstov >Priority: Major > > Currently we have to do synchronized actions in > org/apache/ignite/internal/managers/communication/GridIoManager.java:1124 > (org.apache.ignite.internal.managers.communication.GridIoManager#processRegularMessage) > due to fails on nio thread on load. > We are able to optimize this code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7859) SQL streaming support via native API
[
https://issues.apache.org/jira/browse/IGNITE-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7859.
---
> SQL streaming support via native API
>
>
> Key: IGNITE-7859
> URL: https://issues.apache.org/jira/browse/IGNITE-7859
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
>
> In addition to streaming via thin JDBC driver, ability to run same {{SET
> STREAMING}} command should be added to cache API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-5652) Print slow query warnings on client node
[ https://issues.apache.org/jira/browse/IGNITE-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5652. --- > Print slow query warnings on client node > > > Key: IGNITE-5652 > URL: https://issues.apache.org/jira/browse/IGNITE-5652 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-stability, usability > > Currently, only worker (MAP) nodes of the query print long query execution > time warning to their console, for usability it would be nice to propagate > this to the client node as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9314) MVCC TX: Datastreamer operations
[
https://issues.apache.org/jira/browse/IGNITE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9314:
Component/s: (was: sql)
> MVCC TX: Datastreamer operations
>
>
> Key: IGNITE-9314
> URL: https://issues.apache.org/jira/browse/IGNITE-9314
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Igor Seliverstov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> Need to change DataStreamer semantics (make it transactional)
> Currently clients can see DataStreamer partial writes and two subsequent
> selects, which are run in scope of one transaction at load time, may return
> different results.
> Related thread:
>
> [http://apache-ignite-developers.2346864.n4.nabble.com/MVCC-and-IgniteDataStreamer-td32340.html]
> Also there is a problem when {{DataStreamer}} with {{allowOverwrite ==
> false}} does not insert value when versions for entry exist but they all are
> aborted. Proper transactional semantics should developed for such case. After
> that attention should be put on Cache.size method behavior. Cache.size
> addressed in https://issues.apache.org/jira/browse/IGNITE-8149 could be
> decremented improperly in
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccRemoveAll}}
> method (called during streamer processing) when all existing mvcc row
> versions are aborted or last committed one is _remove_ version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6196) SQL: verify usability of template-based CREATE TABLE operations
[
https://issues.apache.org/jira/browse/IGNITE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6196.
-
Resolution: Won't Fix
Not relevant at the moment. Will reopen if needed.
> SQL: verify usability of template-based CREATE TABLE operations
> ---
>
> Key: IGNITE-6196
> URL: https://issues.apache.org/jira/browse/IGNITE-6196
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: usability
>
> We do not have enough tests and examples on cache template usage for {{CREATE
> TABLE}}. I found only one test which used not template, but existing cache as
> a base for new cache. Let's add more tests with real pre-configured templates
> and extend our documentation accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6415) ALTER TABLE: investigate why descriptor is not updated from GridQueryProcessor#onLocalOperationFinished
[
https://issues.apache.org/jira/browse/IGNITE-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6415.
-
Resolution: Won't Fix
Not relevant at the moment. Will reopen if needed.
> ALTER TABLE: investigate why descriptor is not updated from
> GridQueryProcessor#onLocalOperationFinished
> ---
>
> Key: IGNITE-6415
> URL: https://issues.apache.org/jira/browse/IGNITE-6415
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Priority: Major
>
> For {{CREATE INDEX}} and {{DROP INDEX}} our DDL engine works as follows:
> 1) Update H2 structures from DDL worker thread
> 2) Then update type descriptor from
> {{GridQueryProcessor#onLocalOperationFinished}}
> For some reason {{ALTER TABLE}} handled differently, and we first update
> descriptor, then update H2. See
> {{GridQueryProcessor#processSchemaOperationLocal}}.
> Two questions:
> 1) Why descriptor is updated before H2? In this case we may endup in
> inconsistent state if H2 failed for some reason
> 2) Why we decided not to follow {{CREATE/DROP INDEX}} approach?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7188) MVCC: Retry strategy on lock conflicts
[ https://issues.apache.org/jira/browse/IGNITE-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7188: Summary: MVCC: Retry strategy on lock conflicts (was: SQL TX: Retry strategy on lock conflicts) > MVCC: Retry strategy on lock conflicts > -- > > Key: IGNITE-7188 > URL: https://issues.apache.org/jira/browse/IGNITE-7188 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Priority: Major > > We need to provide some strategy to avoid lock conflicts (deadlocks), detect > and hanle them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7724) SQL COPY: network performance improvements
[ https://issues.apache.org/jira/browse/IGNITE-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7724. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: network performance improvements > -- > > Key: IGNITE-7724 > URL: https://issues.apache.org/jira/browse/IGNITE-7724 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Kirill Shirokov >Assignee: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7681) SQL COPY: local performance improvements
[ https://issues.apache.org/jira/browse/IGNITE-7681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7681. --- > SQL COPY: local performance improvements > > > Key: IGNITE-7681 > URL: https://issues.apache.org/jira/browse/IGNITE-7681 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4, 2.5 >Reporter: Kirill Shirokov >Priority: Major > Attachments: ignite-7681-cache-putall-processor.diff, > ignite-7681-perf-test.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7601) SQL COPY: add tests for implicit columns (_key, _val, _ver)
[ https://issues.apache.org/jira/browse/IGNITE-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7601. - Resolution: Won't Fix Not relevant at the moment. > SQL COPY: add tests for implicit columns (_key, _val, _ver) > --- > > Key: IGNITE-7601 > URL: https://issues.apache.org/jira/browse/IGNITE-7601 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7724) SQL COPY: network performance improvements
[ https://issues.apache.org/jira/browse/IGNITE-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7724: --- Assignee: (was: Kirill Shirokov) > SQL COPY: network performance improvements > -- > > Key: IGNITE-7724 > URL: https://issues.apache.org/jira/browse/IGNITE-7724 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Kirill Shirokov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8402) Long running transaction JMX
[ https://issues.apache.org/jira/browse/IGNITE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-8402. --- > Long running transaction JMX > > > Key: IGNITE-8402 > URL: https://issues.apache.org/jira/browse/IGNITE-8402 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Ivan Kapralov >Priority: Major > > Facing necessity in Long Running Transactions JMX metric implementation. > Needed: transaction start time, node ID, duration, cache full qualified name, > originator ID. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6293) SQL: Support FOREIGN KEY constraint
[
https://issues.apache.org/jira/browse/IGNITE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6293.
---
> SQL: Support FOREIGN KEY constraint
> ---
>
> Key: IGNITE-6293
> URL: https://issues.apache.org/jira/browse/IGNITE-6293
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: sql-engine
>
> We need to support {{FOREIGN KEY}} constraint. This is a complex, though
> achievable thing.
> 1) We need to check constraint during inserts and updates (from both SQL and
> cache API).
> 2) We need to support different modes of {{CASCADE}} actions - "remove", "set
> null".
> In general case it would require distributed operations, possibly with
> predicates. However, as a first iteration, it would be enough to support FK
> only for co-located data. In this case everything could be done locally.
> *Important*
> Implementation of FK typically depends heavily on underlying MVCC and
> transaction subsystems. That said, we should implement it after MVCC and
> transactional SQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7732) SQL COPY: ODBC support
[ https://issues.apache.org/jira/browse/IGNITE-7732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7732: Component/s: (was: sql) > SQL COPY: ODBC support > -- > > Key: IGNITE-7732 > URL: https://issues.apache.org/jira/browse/IGNITE-7732 > Project: Ignite > Issue Type: Task > Components: odbc >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > > Support COPY command for ODBC driver in the same way it is done for JDBC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8598) SQL: ability to control partition pruning with explicit affinity column definition
[
https://issues.apache.org/jira/browse/IGNITE-8598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-8598.
-
Resolution: Duplicate
> SQL: ability to control partition pruning with explicit affinity column
> definition
> --
>
> Key: IGNITE-8598
> URL: https://issues.apache.org/jira/browse/IGNITE-8598
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
>
> Affinity functions are applicable to keys only. Sometimes users may have
> complex affinity calculation logic, so that partition pruning optimization is
> not applicable. E.g. this custom {{AffinityKeyMapper}}. However, there is a
> chance that partition could be calculated from some attribute of {{value}}.
> It would be nice to force our engine to treat some attribute as affinity key
> even though it is not marked as {{AffinityKeyMapped}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10934) Order fields don't work in ignite field queries
[
https://issues.apache.org/jira/browse/IGNITE-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10934:
-
Ignite Flags: (was: Docs Required)
> Order fields don't work in ignite field queries
>
>
> Key: IGNITE-10934
> URL: https://issues.apache.org/jira/browse/IGNITE-10934
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Gaurav Rawat
>Priority: Major
>
> There is an issue when we use fields woth a field such as order . seems the
> H2 query engine recognizes this is a keyword .
> example query :
> SELECT fund.fund_id, fund.close_dt, fund.idea_id, pm .order FROM "fund".FUND
> fund LEFT JOIN "pm ".PM pm ON fund.FUND_ID = pm .FUND_ID limit 40
>
> error :
>
> {code:java}
> Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement .
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.getSyntaxError(DbException.java:217)
> at org.h2.command.Parser.readColumnIdentifier(Parser.java:3507)
> at org.h2.command.Parser.readTermObjectDot(Parser.java:2964)
> at org.h2.command.Parser.readTerm(Parser.java:3095)
> at org.h2.command.Parser.readFactor(Parser.java:2587)
> at org.h2.command.Parser.readSum(Parser.java:2574)
> at org.h2.command.Parser.readConcat(Parser.java:2544)
> at org.h2.command.Parser.readCondition(Parser.java:2370)
> at org.h2.command.Parser.readAnd(Parser.java:2342)
> at org.h2.command.Parser.readExpression(Parser.java:2334)
> at org.h2.command.Parser.parseSelectSimpleSelectPart(Parser.java:2245)
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8913) Uninformative SQL query cancellation message
[
https://issues.apache.org/jira/browse/IGNITE-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8913:
Issue Type: Improvement (was: Bug)
> Uninformative SQL query cancellation message
>
>
> Key: IGNITE-8913
> URL: https://issues.apache.org/jira/browse/IGNITE-8913
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.5
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: iep-29, sql-stability
> Fix For: 2.8
>
> Attachments: sgrimstad_IGNITE_8913_Query_cancelled_me.patch
>
>
> When query timeouted or cancelled or other exception, we getting message:
> "The query was cancelled while executing".
> Need make message more clear - text of query, node which the cancelled,
> reason of cancel query e.t.c.
> {noformat}
> 2018-06-19
> 00:00:10.653[ERROR][query-#93192%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to execute local query.
> org.apache.ignite.cache.query.QueryCancelledException: The query was
> cancelled while executing.
> at
> org.apache.ignite.internal.processors.query.GridQueryCancel.set(GridQueryCancel.java:53)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1115)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:683)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:527)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:218)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:178)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2333)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2018-06-19
> 00:00:11.629[ERROR][query-#93187%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to execute local query.
> org.apache.ignite.cache.query.QueryCancelledException: The query was
> cancelled while executing.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:670)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:527)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:218)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:178)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2333)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7746) Failed to put data into cache if IndexedTypes configured.
[
https://issues.apache.org/jira/browse/IGNITE-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7746.
---
> Failed to put data into cache if IndexedTypes configured.
> -
>
> Key: IGNITE-7746
> URL: https://issues.apache.org/jira/browse/IGNITE-7746
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexey Kuznetsov
>Priority: Major
>
> reproducer
> {code}
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> public class Reproducer {
> /**
> * @param args Command line arguments.
> */
> public static void main(String[] args) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> CacheConfiguration ccfg = new CacheConfiguration("test");
> ccfg.setIndexedTypes(String.class, String.class);
> cfg.setCacheConfiguration(ccfg);
> try(Ignite ignite = Ignition.start(cfg)) {
> IgniteCache cStr = ignite.cache("test");
> cStr.put("key", "value");
> IgniteCache cInt = ignite.cache("test");
> cInt.put(1, 2);
> IgniteCache cIntStr = ignite.cache("test");
> cIntStr.put(7, "test");
> }
> }
> }
> {code}
> {noformat}
> Exception in thread "main"
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [7]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1278)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1731)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1087)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:886)
> at org.apache.ignite.Reproducer.main(Reproducer.java:26)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [7]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1805)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2369)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2346)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> ... 2 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to update
> keys.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKey(UpdateErrors.java:108)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:329)
> at
>
[jira] [Resolved] (IGNITE-7746) Failed to put data into cache if IndexedTypes configured.
[
https://issues.apache.org/jira/browse/IGNITE-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7746.
-
Resolution: Not A Problem
This is expected behavior. Target table is determined by value's type. Since
you defined {{String, String}}, but put {{Integer, String}}, exception is
thrown.
> Failed to put data into cache if IndexedTypes configured.
> -
>
> Key: IGNITE-7746
> URL: https://issues.apache.org/jira/browse/IGNITE-7746
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexey Kuznetsov
>Priority: Major
>
> reproducer
> {code}
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> public class Reproducer {
> /**
> * @param args Command line arguments.
> */
> public static void main(String[] args) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> CacheConfiguration ccfg = new CacheConfiguration("test");
> ccfg.setIndexedTypes(String.class, String.class);
> cfg.setCacheConfiguration(ccfg);
> try(Ignite ignite = Ignition.start(cfg)) {
> IgniteCache cStr = ignite.cache("test");
> cStr.put("key", "value");
> IgniteCache cInt = ignite.cache("test");
> cInt.put(1, 2);
> IgniteCache cIntStr = ignite.cache("test");
> cIntStr.put(7, "test");
> }
> }
> }
> {code}
> {noformat}
> Exception in thread "main"
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [7]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1278)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1731)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1087)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:886)
> at org.apache.ignite.Reproducer.main(Reproducer.java:26)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [7]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1805)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2369)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2346)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> ... 2 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to update
> keys.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKey(UpdateErrors.java:108)
> at
>
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7692: Component/s: cache > affinityCall and affinityRun may execute code on backup partitions > -- > > Key: IGNITE-7692 > URL: https://issues.apache.org/jira/browse/IGNITE-7692 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, usability > Fix For: 2.8 > > > Apparently, the affinityCall and affinityRun methods reserve partitions and > check their state to be OWNING, however, if topology changes and partition > role is changed to backup from primary, the code is still executed. > This can be an issue if a user executes a local SQL query inside the > affinityCall runnable. In this case, the query result may return null. > This can be observed in the > IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note > an additional check I've added to make the test pass. > I think it is ok to have an old semantics for the API, because in some cases > (scan query, local gets) a backup OWNER is enough. However, it looks like we > need to add another API method to enforce that affinity run be executed on > primary nodes and forbid primary role change. > Another option is to detect a topology version of the affinity run and use > that version for local SQL queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7372) Implement escape sequences handling in internal SQL parser
[ https://issues.apache.org/jira/browse/IGNITE-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7372. - Resolution: Won't Fix Not relevant at the moment. > Implement escape sequences handling in internal SQL parser > -- > > Key: IGNITE-7372 > URL: https://issues.apache.org/jira/browse/IGNITE-7372 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Kirill Shirokov >Priority: Minor > > Implement escape sequences handling inside quoted literals. > The initial implementation is pruned from IGNITE-6861 and put into this > feature branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7374) Add 'default' as a possible value for an SQL command parameter
[ https://issues.apache.org/jira/browse/IGNITE-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7374. - Resolution: Won't Fix Not relevant at the moment. > Add 'default' as a possible value for an SQL command parameter > -- > > Key: IGNITE-7374 > URL: https://issues.apache.org/jira/browse/IGNITE-7374 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > > There should be a possibility to specify default value for parameters > (numeric, string and enum) using 'default' keyword. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7544) SQL COPY command: implement statistics gathering and error reporting
[ https://issues.apache.org/jira/browse/IGNITE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7544. --- > SQL COPY command: implement statistics gathering and error reporting > > > Key: IGNITE-7544 > URL: https://issues.apache.org/jira/browse/IGNITE-7544 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > > In the COPY command we might be interested in how many rows: > * have been added > * have been updated > * have been skipped > * had errors > The numbers above can be reported as a row with corresponding columns. Errors > can be reported as a cursor with appropriate rows. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7374) Add 'default' as a possible value for an SQL command parameter
[ https://issues.apache.org/jira/browse/IGNITE-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7374. --- > Add 'default' as a possible value for an SQL command parameter > -- > > Key: IGNITE-7374 > URL: https://issues.apache.org/jira/browse/IGNITE-7374 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > > There should be a possibility to specify default value for parameters > (numeric, string and enum) using 'default' keyword. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8732) SQL: REPLICATED cache cannot be left-joined to PARTITIONED
[
https://issues.apache.org/jira/browse/IGNITE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8732:
Issue Type: Improvement (was: Bug)
> SQL: REPLICATED cache cannot be left-joined to PARTITIONED
> --
>
> Key: IGNITE-8732
> URL: https://issues.apache.org/jira/browse/IGNITE-8732
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: sql-engine
>
> *Steps to reproduce*
> # Run
> {{org.apache.ignite.sqltests.ReplicatedSqlTest#testLeftJoinReplicatedPartitioned}}
> # Observe that we have 2x results on 2-node cluster
> *Root Cause*
> {{left LEFT JOIN right ON cond}} operation assumes full scan of of a left
> expression. Currently we perform this scan on every node and then simply
> merge results on reducer. Two nodes, two scans of {{REPLICATED}} cache, 2x
> results.
> *Potential Solutions*
> We may consider several solutions. Deeper analysis is required to understand
> which is the right one.
> # Perform deduplication on reducer - this most prospective and general
> technique, described in more details below
> # Treat {{REPLICATED}} cache as {{PARTITIONED}}. Essentially, we just need to
> pass proper backup filter. But what if {{REPLICATED}} cache spans more nodes
> than {{PARTITIONED}}? We cannot rely on primary/backup in this case
> # Implement additional execution phase as follows:
> {code}
> SELECT left.cols, right.cols FROM left INNER JOIN right ON cond;
> // Get "inner join" part
> UNION
> UNICAST SELECT left.cols, [NULL].cols FROM left WHERE left.id NOT IN ([ids
> from the first phase]) // Get "outer join" part
> {code}
> *Reducer Deduplication*
> The idea is to get all data locally and then perform final deduplication.
> This may incur high network overhead, because of lot of duplicated left parts
> would be transferred. However, this could be optimized greatly with the
> following techniques applied one after another
> # Semi-jions: {{left}} is {{joined}} on mapper node, but instead of sending
> {{(left, right)}} relation, we send {{(left) + (right)}}
> # In case {{left}} part is known to be idempotent (i.e. it produces the same
> result set on all nodes), only one node will send {{(left) + (right)}}, other
> nodes will send {{(right)}} only
> # Merge {{left}} results with if needed (i.e. if idempotence-related opto was
> not applicable)
> # Join {{left}} and {{right}} parts on reducer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7542) SQL COPY command: implement multipliers (e.g., 'K' for kilo-, 'M' for mega-) in numbers
[
https://issues.apache.org/jira/browse/IGNITE-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7542.
---
Not relevant for now.
> SQL COPY command: implement multipliers (e.g., 'K' for kilo-, 'M' for mega-)
> in numbers
> ---
>
> Key: IGNITE-7542
> URL: https://issues.apache.org/jira/browse/IGNITE-7542
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Kirill Shirokov
>Priority: Minor
>
> Multipliers can be important for several options, such as batch size.
> The syntax could be:
> {noformat}
> COPY
> ...
> BATCH_SIZE 1.5M
> {noformat}
> Such number can have a decimal point and an optional multiplier:
> K: 1024
> M: 1024 * 1024
> ...and so on for giga-, tera-, and peta-
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11311) MVCC: SQL full table scan query can return duplicates.
[ https://issues.apache.org/jira/browse/IGNITE-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11311: -- Description: SQL query like "select * from table" can return duplicate rows. Possible reasons are * SQL query iterates over data pages directly and can see inconsistent state (IGNITE-10561) * Query see stale pages. See IGNITE-10767 for details. * Smth is wrong with mvcc versions visibility. was: SQL query like "select * from table" can return duplicate rows. Possible reasons can be * due to SQL query iterates over data pages directly and can see inconsistent state (IGNITE-10561) * Same as IGNITE-10767, query see stale pages. * Smth is wrong with mvcc versions visibility. > MVCC: SQL full table scan query can return duplicates. > -- > > Key: IGNITE-11311 > URL: https://issues.apache.org/jira/browse/IGNITE-11311 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Priority: Major > > SQL query like "select * from table" can return duplicate rows. > Possible reasons are > * SQL query iterates over data pages directly and can see inconsistent state > (IGNITE-10561) > * Query see stale pages. See IGNITE-10767 for details. > * Smth is wrong with mvcc versions visibility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7553) SQL COPY: provide support for the command in org.apache.ignite.internal.jdbc2 driver
[ https://issues.apache.org/jira/browse/IGNITE-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7553. --- > SQL COPY: provide support for the command in org.apache.ignite.internal.jdbc2 > driver > > > Key: IGNITE-7553 > URL: https://issues.apache.org/jira/browse/IGNITE-7553 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Minor > > Currently COPY command is supported only in thin JDBC driver. It needs to be > supported in other JDBC driver implementations as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7541) SQL COPY command: implement backend switching option
[
https://issues.apache.org/jira/browse/IGNITE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7541.
-
Resolution: Won't Fix
Not relevant at the moment.
> SQL COPY command: implement backend switching option
>
>
> Key: IGNITE-7541
> URL: https://issues.apache.org/jira/browse/IGNITE-7541
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Kirill Shirokov
>Priority: Major
>
> When we load data using COPY command we can add key/value pairs to the cache
> using different ways:
> * Directly calling cache.putAll()
> * Loading data via DataStreamer
> * etc.
> Every backend has its pros and cons. For example, the streamer is fast and
> asynchronous, although it cannot replace value and cannot provide any
> statistics -- such as number of added records. The direct interface is slow
> and synchronous, but provides us with an ability to either replace or skip
> the records with the same key and respond to the user with full statistics.
> There shall be an option in the SQL command to switch to particular backend.
> For example:
> {noformat}
> COPY
> FROM 'file'
> ...
> [BACKEND (DIRECT | STREAMER)]
> We might have more backends in the future.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7738) Allow 'multiple statements' in thin JDBC streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7738. - Resolution: Won't Fix Not needed at the moment. > Allow 'multiple statements' in thin JDBC streaming mode > --- > > Key: IGNITE-7738 > URL: https://issues.apache.org/jira/browse/IGNITE-7738 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Priority: Major > > We need to update thin JDBC protocol to let user run multiple statements via > Statement.execute(String) when connection is in streamed mode. Currently in > streaming mode the server always receives all SQL in batches and its batch > processing logic does not allow multiple statements altogether. If we're able > to recognize initial nature of the statement, we'll be able to act > appropriately, and for this to be possible additional information must be > passed with each query in the batch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5277) Asynchronously establish connection to all the needed nodes in IgniteH2Indexing.send()
[ https://issues.apache.org/jira/browse/IGNITE-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5277. - Resolution: Won't Fix Not relevant at the moment. > Asynchronously establish connection to all the needed nodes in > IgniteH2Indexing.send() > -- > > Key: IGNITE-5277 > URL: https://issues.apache.org/jira/browse/IGNITE-5277 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: sql-performance > > it's only a minor optimization until the point when establishing each > connection takes 3-4 seconds, and we establish 32 of them in sequence. At > that point it becomes a serious issue: the customer cannot run SQL queries > from their development machines -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5277) Asynchronously establish connection to all the needed nodes in IgniteH2Indexing.send()
[ https://issues.apache.org/jira/browse/IGNITE-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5277. --- > Asynchronously establish connection to all the needed nodes in > IgniteH2Indexing.send() > -- > > Key: IGNITE-5277 > URL: https://issues.apache.org/jira/browse/IGNITE-5277 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: sql-performance > > it's only a minor optimization until the point when establishing each > connection takes 3-4 seconds, and we establish 32 of them in sequence. At > that point it becomes a serious issue: the customer cannot run SQL queries > from their development machines -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7027) SQL: Single primary index instead of mulitple per-partition indexes
[ https://issues.apache.org/jira/browse/IGNITE-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7027. --- > SQL: Single primary index instead of mulitple per-partition indexes > --- > > Key: IGNITE-7027 > URL: https://issues.apache.org/jira/browse/IGNITE-7027 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Priority: Major > Labels: iep-19, performance > > Currently we have per-partition primary index. This gives us easy and > effective rebalance/recovery capabilities and efficient lookup in key-value > mode. > However, this doesn't work well for SQL case. We cannot use this index for > range scans. Neither we can use it for PK lookups (it is possible to > implement, but will be less then optimal due to necessity to build the whole > key object). > The following change is suggested as optional storage mode: > 1) Single index data structure for all partitions > 2) Only single key type is allowed (i.e. no mess in the cache and no cache > groups) > 3) Additional SQL PK index will not be needed in this case > Advantage: > - No overhead on the second PK index > Disadvantage: > - Less efficient rebalance and recovery -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6292) SQL: Support CHECK constraint
[
https://issues.apache.org/jira/browse/IGNITE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6292.
---
> SQL: Support CHECK constraint
> -
>
> Key: IGNITE-6292
> URL: https://issues.apache.org/jira/browse/IGNITE-6292
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: sql-engine
>
> Currently we do not support {{CHECK}} constraint, which is very important in
> SQL world. Need to investigate how we can add it. Essentially, we have two
> ways:
> 1) Either delegate constraint validation to H2 somehow. But remember that we
> should do that early during update, and we should do that efficiently. Need
> to investigate H2 API to find out how to achieve that.
> 2) Or we should wait for development of our own execution engine, which is a
> huge thing and would not appear fast. In this case we would be able to
> pre-compile expression somehow and execute it whenever we want.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7027) SQL: Single primary index instead of mulitple per-partition indexes
[ https://issues.apache.org/jira/browse/IGNITE-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7027: Labels: performance (was: iep-19 performance) > SQL: Single primary index instead of mulitple per-partition indexes > --- > > Key: IGNITE-7027 > URL: https://issues.apache.org/jira/browse/IGNITE-7027 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > Currently we have per-partition primary index. This gives us easy and > effective rebalance/recovery capabilities and efficient lookup in key-value > mode. > However, this doesn't work well for SQL case. We cannot use this index for > range scans. Neither we can use it for PK lookups (it is possible to > implement, but will be less then optimal due to necessity to build the whole > key object). > The following change is suggested as optional storage mode: > 1) Single index data structure for all partitions > 2) Only single key type is allowed (i.e. no mess in the cache and no cache > groups) > 3) Additional SQL PK index will not be needed in this case > Advantage: > - No overhead on the second PK index > Disadvantage: > - Less efficient rebalance and recovery -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9224) MVCC SQL: Cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-9224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9224:
Component/s: (was: sql)
> MVCC SQL: Cache metrics
> ---
>
> Key: IGNITE-9224
> URL: https://issues.apache.org/jira/browse/IGNITE-9224
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> We need to support {{CacheMetrics}} API for MVCC caches. Semantics should
> conform JCache specification. Only committed stores and removes should be
> counted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
[ https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7766: Issue Type: Bug (was: Task) > Ignite Queries 2: Test always failed > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > --- > > Key: IGNITE-7766 > URL: https://issues.apache.org/jira/browse/IGNITE-7766 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Dmitriy Pavlov >Assignee: Evgenii Zagumennov >Priority: Major > Labels: MakeTeamcityGreenAgain, sql-stability > > Ignite Queries 2 > IgniteBinaryCacheQueryTestSuite2: > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%) > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > Current failure: refs/heads/master #345 No changes 11 Feb 18 03:03 > junit.framework.AssertionFailedError: On large page size must retry. > Last runs fails with 100% probability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7188) MVCC: Retry strategy on lock conflicts
[ https://issues.apache.org/jira/browse/IGNITE-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7188: Component/s: (was: sql) > MVCC: Retry strategy on lock conflicts > -- > > Key: IGNITE-7188 > URL: https://issues.apache.org/jira/browse/IGNITE-7188 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > We need to provide some strategy to avoid lock conflicts (deadlocks), detect > and hanle them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7187) MVCC: Near caches support
[ https://issues.apache.org/jira/browse/IGNITE-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7187: Summary: MVCC: Near caches support (was: SQL TX: Near caches support) > MVCC: Near caches support > - > > Key: IGNITE-7187 > URL: https://issues.apache.org/jira/browse/IGNITE-7187 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Priority: Major > > Currently near readers don't participate in SQL transactions, we need to > notify near readers on updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6201) SQL: support merge join
[
https://issues.apache.org/jira/browse/IGNITE-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6201.
-
Resolution: Won't Fix
Not relevant at the moment.
> SQL: support merge join
>
>
> Key: IGNITE-6201
> URL: https://issues.apache.org/jira/browse/IGNITE-6201
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: sql-engine
>
> It looks like currently the only way to join data is {{nested loops}}
> approach. While being perfectly fine for small tables, this approach is
> terribly inefficient for joins on large tables. We need to make sure that
> merge join technique is used instead if join is performed on sorted
> attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7859) SQL streaming support via native API
[
https://issues.apache.org/jira/browse/IGNITE-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7859.
-
Resolution: Won't Fix
Not relevant at the moment.
> SQL streaming support via native API
>
>
> Key: IGNITE-7859
> URL: https://issues.apache.org/jira/browse/IGNITE-7859
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
>
> In addition to streaming via thin JDBC driver, ability to run same {{SET
> STREAMING}} command should be added to cache API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7187) MVCC: Near caches support
[ https://issues.apache.org/jira/browse/IGNITE-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7187: Component/s: (was: sql) > MVCC: Near caches support > - > > Key: IGNITE-7187 > URL: https://issues.apache.org/jira/browse/IGNITE-7187 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > Currently near readers don't participate in SQL transactions, we need to > notify near readers on updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7966) MVCC TX Review cache/Ignite configuration for MVCC needs
[ https://issues.apache.org/jira/browse/IGNITE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7966: Component/s: (was: sql) > MVCC TX Review cache/Ignite configuration for MVCC needs > > > Key: IGNITE-7966 > URL: https://issues.apache.org/jira/browse/IGNITE-7966 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > > We need to rethink Ignite and Cache configuration to have a control on such > parameters as VACUUM frequency, TxLog data-region parameters, whether MVCC > enabled or not for particular cache etc. Most of such parameters are > hardcoded now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8600) SQL: lazy row materialization
[ https://issues.apache.org/jira/browse/IGNITE-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-8600. - Resolution: Won't Fix Not relevant at the moment. Will reopen if needed. > SQL: lazy row materialization > - > > Key: IGNITE-8600 > URL: https://issues.apache.org/jira/browse/IGNITE-8600 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.5 >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > Currently our index cursor materializes rows as soon as they are encountered > in an index page. This is necessary to protect ourselves from concurrent data > modification. However, materialized rows might be filtered out later due to > additional filters. In addition, there is a chance that only indexed fields > is needed by query. > We can do the following: > 1) Introduce new mode that will return partially materialized rows, with only > inline index fields initialized. When some non-initialized attribute is > requested, we go to data page and materialize the whole row > 2) Enable this mode for MVCC by default > 3) Optionally enable this mode for non-MVCC read-only mode through additional > flag. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6903) Implement new JMX metrics for Indexing
[ https://issues.apache.org/jira/browse/IGNITE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6903. - Resolution: Won't Fix Not relevant at the moment. Will reopen if needed. > Implement new JMX metrics for Indexing > -- > > Key: IGNITE-6903 > URL: https://issues.apache.org/jira/browse/IGNITE-6903 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Anton Vinogradov >Priority: Critical > Labels: iep-6, important > Fix For: 2.8 > > > These additional metrics and methods should be implemented: > - Space occupied by indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4575) Implement wrapper for enums based on H2 user value type
[ https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4575. - Resolution: Won't Fix Not relevant at the moment. Will reopen if needed. > Implement wrapper for enums based on H2 user value type > --- > > Key: IGNITE-4575 > URL: https://issues.apache.org/jira/browse/IGNITE-4575 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-engine > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8402) Long running transaction JMX
[ https://issues.apache.org/jira/browse/IGNITE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-8402. - Resolution: Won't Fix Not relevant at the moment. Will reopen if needed. > Long running transaction JMX > > > Key: IGNITE-8402 > URL: https://issues.apache.org/jira/browse/IGNITE-8402 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Ivan Kapralov >Priority: Major > > Facing necessity in Long Running Transactions JMX metric implementation. > Needed: transaction start time, node ID, duration, cache full qualified name, > originator ID. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5653) Add to query execution plan debug data for joins
[ https://issues.apache.org/jira/browse/IGNITE-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5653. - Resolution: Won't Fix Not relevant at the moment. Will reopen if needed. > Add to query execution plan debug data for joins > > > Key: IGNITE-5653 > URL: https://issues.apache.org/jira/browse/IGNITE-5653 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-stability, usability > > Plan should output table type (replicated/partitioned) and colocation > information if possible. If we have this than we can warn (or throw > exception) if users try to join non colocated tables with local joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5653) Add to query execution plan debug data for joins
[ https://issues.apache.org/jira/browse/IGNITE-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5653. --- > Add to query execution plan debug data for joins > > > Key: IGNITE-5653 > URL: https://issues.apache.org/jira/browse/IGNITE-5653 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-stability, usability > > Plan should output table type (replicated/partitioned) and colocation > information if possible. If we have this than we can warn (or throw > exception) if users try to join non colocated tables with local joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7846) SQL: support COPY command by native SQL
[ https://issues.apache.org/jira/browse/IGNITE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7846. - Resolution: Won't Fix Assignee: (was: Taras Ledkov) > SQL: support COPY command by native SQL > --- > > Key: IGNITE-7846 > URL: https://issues.apache.org/jira/browse/IGNITE-7846 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.3 >Reporter: Taras Ledkov >Priority: Major > > The COPY command is supported only for JDBC client (IGNITE-6917). > It must be supported by native SQL API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5652) Print slow query warnings on client node
[ https://issues.apache.org/jira/browse/IGNITE-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5652. - Resolution: Won't Fix Not relevant at the moment. Will reopen if needed. > Print slow query warnings on client node > > > Key: IGNITE-5652 > URL: https://issues.apache.org/jira/browse/IGNITE-5652 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-stability, usability > > Currently, only worker (MAP) nodes of the query print long query execution > time warning to their console, for usability it would be nice to propagate > this to the client node as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7846) SQL: support COPY command by native SQL
[ https://issues.apache.org/jira/browse/IGNITE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7846. --- > SQL: support COPY command by native SQL > --- > > Key: IGNITE-7846 > URL: https://issues.apache.org/jira/browse/IGNITE-7846 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.3 >Reporter: Taras Ledkov >Priority: Major > > The COPY command is supported only for JDBC client (IGNITE-6917). > It must be supported by native SQL API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5951) DDL: Support CREATE VIEW
[ https://issues.apache.org/jira/browse/IGNITE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5951. --- > DDL: Support CREATE VIEW > > > Key: IGNITE-5951 > URL: https://issues.apache.org/jira/browse/IGNITE-5951 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vyacheslav Koptilin >Priority: Minor > Labels: sql-engine > > Ignite should support sql VIEW. > The issue was mentioned on Stack Overflow: > https://stackoverflow.com/questions/45542016/unable-to-create-a-view-in-apache-ignite/45543134 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7743) JDBC driver allows to connect to non existent schema
[
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7743:
Component/s: (was: sql)
> JDBC driver allows to connect to non existent schema
>
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
> Labels: usability
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or
> {{indexedTypes}}), separate schema for this cache is created. Schema name is
> case sensitive, so to connect to it with JDBC driver, it's required to
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that
> does not exist, throw exception in this case. Exception should provide proper
> explanation how to connect properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10937) Support data page scan for JDBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10937: - Component/s: (was: sql) jdbc > Support data page scan for JDBC > --- > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Sergi Vladykin >Assignee: Pavel Kuznetsov >Priority: Major > Labels: performance > > In scope jdbc v2 and thin drivers > We need to add connection property that reflects states of data page scan > feature: enabled/disabled/not defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6261) ODBC support for Mac OSX
[ https://issues.apache.org/jira/browse/IGNITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6261: Component/s: (was: sql) > ODBC support for Mac OSX > > > Key: IGNITE-6261 > URL: https://issues.apache.org/jira/browse/IGNITE-6261 > Project: Ignite > Issue Type: Improvement > Components: odbc >Affects Versions: 2.1 > Environment: Analytics >Reporter: Pranas Baliuka >Assignee: Igor Sapego >Priority: Major > Labels: usability > > In order for Ignite to be useful in analytics environment (accessing data via > R / Most reporting engines), the ODBC access is required. > Analyst do use Mac OSX (not only Linux/Windows). > The current ODBC driver is not compilable on OSX due to 1-2 different kernel > API functions. > Similar incompatibility issues are already resolved in similar projects using > conditional macros in C language. i.e. it may not be a big challenge to make > it work. > Thanks for planning and considerations! > PS: > For my use case the issue is a Blocker, because rJAVA is dead (requires Java > 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is > not working for R (class cast exceptions). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11309) JDBC Thin: add flag or property to disable best effort affinity
[ https://issues.apache.org/jira/browse/IGNITE-11309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11309: - Component/s: (was: sql) jdbc > JDBC Thin: add flag or property to disable best effort affinity > --- > > Key: IGNITE-11309 > URL: https://issues.apache.org/jira/browse/IGNITE-11309 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.8 >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23 > > It's necessary to have an ability to disable best effort affinity among thin > clients including thin jdbc client. > It's not obvious whether it should be flag in connection string, app > properties or some other place, so research required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7164) MVCC: Remap protocol
[ https://issues.apache.org/jira/browse/IGNITE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7164: Component/s: (was: sql) > MVCC: Remap protocol > > > Key: IGNITE-7164 > URL: https://issues.apache.org/jira/browse/IGNITE-7164 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Minor > Fix For: 2.8 > > > We need to provide remap protocol on topology changes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7164) MVCC: Remap protocol
[ https://issues.apache.org/jira/browse/IGNITE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7164: Summary: MVCC: Remap protocol (was: SQL TX: Remap protocol) > MVCC: Remap protocol > > > Key: IGNITE-7164 > URL: https://issues.apache.org/jira/browse/IGNITE-7164 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Priority: Minor > Fix For: 2.8 > > > We need to provide remap protocol on topology changes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9771) Indirect SQL queries are failing
[ https://issues.apache.org/jira/browse/IGNITE-9771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-9771. - Resolution: Won't Fix Not relevant at the moment. > Indirect SQL queries are failing > > > Key: IGNITE-9771 > URL: https://issues.apache.org/jira/browse/IGNITE-9771 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > Attachments: sgrimstad_IGNITE_9771_implementation_.patch > > > Attempt to sql query (not sql fields query ) another cache's type leads to > exception: > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > find SQL table for type: ... > IgniteH2Indexing#queryDistributedSql in the beginning of the method logic > there is check of schemaName, cacheName and type. First two parameters passed > belong to called cache while third belongs to target cache. This combination > leads to the exception mentioned. > # Create tests to reproduce the situation > # Fix problem > # Enable commented out tests with 'todo' and this ticket number reference -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9644) SQL: local DML query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-9644. - Resolution: Won't Fix Not relevant at the moment. > SQL: local DML query should pin affected partitions > --- > > Key: IGNITE-9644 > URL: https://issues.apache.org/jira/browse/IGNITE-9644 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > Related to IGNITE-7039. Need to expand for DML. Commented out test market as > TODO: IGNITE-9644 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9644) SQL: local DML query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-9644. --- > SQL: local DML query should pin affected partitions > --- > > Key: IGNITE-9644 > URL: https://issues.apache.org/jira/browse/IGNITE-9644 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > Related to IGNITE-7039. Need to expand for DML. Commented out test market as > TODO: IGNITE-9644 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7687) SQL SELECT doesn't update TTL for Touched/AccessedExpiryPolicy
[
https://issues.apache.org/jira/browse/IGNITE-7687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7687:
Issue Type: Task (was: Improvement)
> SQL SELECT doesn't update TTL for Touched/AccessedExpiryPolicy
> --
>
> Key: IGNITE-7687
> URL: https://issues.apache.org/jira/browse/IGNITE-7687
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.5
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> SQL SELECT queries don't update TTLs when TouchedExpiryPolicy or
> AccessedExpiryPolicy is used (unlike IgniteCache::get which does update the
> TTLs).
> Example (modified SqlDmlExample):
>
> CacheConfiguration orgCacheCfg = new
> CacheConfiguration(ORG_CACHE)
> .setIndexedTypes(Long.class, Organization.class)
> .setExpiryPolicyFactory(TouchedExpiryPolicy.factoryOf(new
> Duration(TimeUnit.SECONDS, 10)));
>
> IgniteCache orgCache =
> ignite.getOrCreateCache(orgCacheCfg);
>
> SqlFieldsQuery qry = new SqlFieldsQuery("insert into Organization (_key,
> id, name) values (?, ?, ?)");
> orgCache.query(qry.setArgs(1L, 1L, "ASF"));
> orgCache.query(qry.setArgs(2L, 2L, "Eclipse"));
>
> SqlFieldsQuery qry1 = new SqlFieldsQuery("select id, name from
> Organization as o");
> for (int i = 0; ;i++) {
> List> res = orgCache.query(qry1).getAll();
> print("i = " + i);
> for (Object next : res)
> System.out.println(">>> " + next);
> U.sleep(5000);
> }
>
> Output:
> >>> i = 0
> >>> [1, ASF]
> >>> [2, Eclipse]
> >>> i = 1
> >>> [1, ASF]
> >>> [2, Eclipse]
> >>> i = 2
> >>> i = 3
> ...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-10934) Order fields don't work in ignite field queries
[
https://issues.apache.org/jira/browse/IGNITE-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-10934.
> Order fields don't work in ignite field queries
>
>
> Key: IGNITE-10934
> URL: https://issues.apache.org/jira/browse/IGNITE-10934
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Gaurav Rawat
>Priority: Major
>
> There is an issue when we use fields woth a field such as order . seems the
> H2 query engine recognizes this is a keyword .
> example query :
> SELECT fund.fund_id, fund.close_dt, fund.idea_id, pm .order FROM "fund".FUND
> fund LEFT JOIN "pm ".PM pm ON fund.FUND_ID = pm .FUND_ID limit 40
>
> error :
>
> {code:java}
> Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement .
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.getSyntaxError(DbException.java:217)
> at org.h2.command.Parser.readColumnIdentifier(Parser.java:3507)
> at org.h2.command.Parser.readTermObjectDot(Parser.java:2964)
> at org.h2.command.Parser.readTerm(Parser.java:3095)
> at org.h2.command.Parser.readFactor(Parser.java:2587)
> at org.h2.command.Parser.readSum(Parser.java:2574)
> at org.h2.command.Parser.readConcat(Parser.java:2544)
> at org.h2.command.Parser.readCondition(Parser.java:2370)
> at org.h2.command.Parser.readAnd(Parser.java:2342)
> at org.h2.command.Parser.readExpression(Parser.java:2334)
> at org.h2.command.Parser.parseSelectSimpleSelectPart(Parser.java:2245)
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7548) SQL COPY: handle CSV lines with less values than required correctly
[
https://issues.apache.org/jira/browse/IGNITE-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7548.
---
> SQL COPY: handle CSV lines with less values than required correctly
> ---
>
> Key: IGNITE-7548
> URL: https://issues.apache.org/jira/browse/IGNITE-7548
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>
> Currently some of lines in CSV files can have less values than declared in
> the command or CSV header.
> We need to think how do we handle such rows:
> * append empty values ("") for the missing trailing columns
> * append null values
> * reject such lines and report an error
> We might need a COPY command parameter to configure the desired behaviour.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7554) SQL COPY: consider providing support for the command in batch mode
[ https://issues.apache.org/jira/browse/IGNITE-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7554. - Resolution: Won't Fix Not relevant for now. > SQL COPY: consider providing support for the command in batch mode > -- > > Key: IGNITE-7554 > URL: https://issues.apache.org/jira/browse/IGNITE-7554 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > > Currently SQL COPY command rejects to execute in JDBC batch mode (via > java.sql.Statement.addBatch() + executeBatch()). > If we want COPY to be executed in batch mode we need to implement it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7545) SQL COPY command: implement duplicate handling strategy
[
https://issues.apache.org/jira/browse/IGNITE-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7545.
---
> SQL COPY command: implement duplicate handling strategy
> ---
>
> Key: IGNITE-7545
> URL: https://issues.apache.org/jira/browse/IGNITE-7545
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>
> The SQL COPY command should have user-configurable policy of handling
> duplicate records:
> {noformat}
> COPY
> ...
> [(REPLACE | IGNORE| ABORT ON [])) DUPLICATE KEYS]
> {noformat}
> This handling might be not available for some backends (e.g., streamer).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7544) SQL COPY command: implement statistics gathering and error reporting
[ https://issues.apache.org/jira/browse/IGNITE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7544. - Resolution: Won't Fix Not relevant for now. > SQL COPY command: implement statistics gathering and error reporting > > > Key: IGNITE-7544 > URL: https://issues.apache.org/jira/browse/IGNITE-7544 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Major > > In the COPY command we might be interested in how many rows: > * have been added > * have been updated > * have been skipped > * had errors > The numbers above can be reported as a row with corresponding columns. Errors > can be reported as a cursor with appropriate rows. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7545) SQL COPY command: implement duplicate handling strategy
[
https://issues.apache.org/jira/browse/IGNITE-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7545.
-
Resolution: Won't Fix
Not relevant for now.
> SQL COPY command: implement duplicate handling strategy
> ---
>
> Key: IGNITE-7545
> URL: https://issues.apache.org/jira/browse/IGNITE-7545
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>
> The SQL COPY command should have user-configurable policy of handling
> duplicate records:
> {noformat}
> COPY
> ...
> [(REPLACE | IGNORE| ABORT ON [])) DUPLICATE KEYS]
> {noformat}
> This handling might be not available for some backends (e.g., streamer).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7546) SQL COPY command: implement CSV header row parsing
[
https://issues.apache.org/jira/browse/IGNITE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7546.
-
Resolution: Won't Fix
Not relevant for now.
> SQL COPY command: implement CSV header row parsing
> --
>
> Key: IGNITE-7546
> URL: https://issues.apache.org/jira/browse/IGNITE-7546
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Major
>
> Implement optional reading of CSV format header row and matching it to column
> numbers.
> So, there are the following options:
> * just skip the header row (or arbitrary number of rows)
> * match the fields in the header row to the query entity columns and map them
> to the column list
> A possible syntax for this option might look like this:
> {noformat}
> COPY
> ...
> [(MATCH | SKIP) HEADER]
> {noformat}
> When implementing this feature please keep in mind that we might have an
> option for skipping user-specified number of header lines / left columns and
> importing only user-specified number of lines and columns.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
