[jira] [Closed] (IGNITE-3823) Add nested joins support
[ https://issues.apache.org/jira/browse/IGNITE-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3823. --- > Add nested joins support > > > Key: IGNITE-3823 > URL: https://issues.apache.org/jira/browse/IGNITE-3823 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.7 >Reporter: Igor Sapego >Priority: Major > Labels: sql-engine > > Currently, nested joins are not supported as well as any other query that get > reduced to the nested join. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-3768) SQL: implement collecting query metrics from map step to reduce step
[ https://issues.apache.org/jira/browse/IGNITE-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3768. --- > SQL: implement collecting query metrics from map step to reduce step > > > Key: IGNITE-3768 > URL: https://issues.apache.org/jira/browse/IGNITE-3768 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Priority: Major > > Ignite SQL engine use a mapreduce to execute query on cluster. > Some node map queries over cluster and after they are completed and reduced > on initial node. > In current implementation we measure duration on initial node and on all > nodes where two-step queries are executed, but only overall duration is > returned. > We also need to return duration from all two-step queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-3768) SQL: implement collecting query metrics from map step to reduce step
[ https://issues.apache.org/jira/browse/IGNITE-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3768. - Resolution: Duplicate Will be fixed at some point as a part of IEP-29. > SQL: implement collecting query metrics from map step to reduce step > > > Key: IGNITE-3768 > URL: https://issues.apache.org/jira/browse/IGNITE-3768 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Priority: Major > > Ignite SQL engine use a mapreduce to execute query on cluster. > Some node map queries over cluster and after they are completed and reduced > on initial node. > In current implementation we measure duration on initial node and on all > nodes where two-step queries are executed, but only overall duration is > returned. > We also need to return duration from all two-step queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3453) Query engine picks incorrect index in certain configurations.
[ https://issues.apache.org/jira/browse/IGNITE-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3453: Labels: performance (was: sql-performance) > Query engine picks incorrect index in certain configurations. > - > > Key: IGNITE-3453 > URL: https://issues.apache.org/jira/browse/IGNITE-3453 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexei Scherbakov >Priority: Major > Labels: performance > Attachments: Example.java > > > Index selection depends on index name ordering, not the argument type. > Index 1 (name idx_1): > countryId:Integer, regionId:Integer, cityId:Integer > Index 2 (name idx_0): > countryId:Integer, regionId:Integer, nation:String > For query: > select id, countryId, cityId from Person where countryId=? and regionId=? and > cityId=? params 1,1,1 > the index 2 is picked incorrectly and only two first fields are used. > See full reproducer in the attachment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3171) Support column selectivity calculation for SQL
[ https://issues.apache.org/jira/browse/IGNITE-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3171: Labels: (was: sql-engine sql-performance) > Support column selectivity calculation for SQL > -- > > Key: IGNITE-3171 > URL: https://issues.apache.org/jira/browse/IGNITE-3171 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Sergi Vladykin >Priority: Major > > Need to support ANALYZE command. > http://h2database.com/html/grammar.html#analyze > Currently H2 explicitly ignores external table engines (don't see any reasons > why). Probably we have to fix H2 by adding method Table.canAnalyze() and use > it in that check. > Also when IGNITE-1232 will be merged we'll need to propagate this statistics > to clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7761) EXPLAIN with run time statistics
[ https://issues.apache.org/jira/browse/IGNITE-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7761. - Resolution: Won't Fix Will be handled as a part of IEP-29. Probably design will be completely different. See also IGNITE-3171, IGNITE-6079, IGNITE-9778 > EXPLAIN with run time statistics > > > Key: IGNITE-7761 > URL: https://issues.apache.org/jira/browse/IGNITE-7761 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Priority: Major > > For performance tuning of the sql queries It is nice to have actual run time > statistics of the query execution. > Statistics could include elapsed time and the number of rows for each query > node. > Example: > > ||Rows||Actual Time||Plan Node|| || > |1|5ms|group by city|Index scan using person.city| > |20|30ms|person.age=5|Full scan(person.age)| > |131231|50ms|person.name='John'|Index scan using person_name_idx| > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4489) Maintain correct MERGE semantic in DML
[ https://issues.apache.org/jira/browse/IGNITE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4489. - Resolution: Won't Fix > Maintain correct MERGE semantic in DML > -- > > Key: IGNITE-4489 > URL: https://issues.apache.org/jira/browse/IGNITE-4489 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > > Currently it's impossible to MERGE object in UPDATE style - i.e. when key is > present in cache, unaffected field values should be retained, and instead of > building new object we should base it on previous one for given key. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-4489) Maintain correct MERGE semantic in DML
[ https://issues.apache.org/jira/browse/IGNITE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reopened IGNITE-4489: - > Maintain correct MERGE semantic in DML > -- > > Key: IGNITE-4489 > URL: https://issues.apache.org/jira/browse/IGNITE-4489 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > > Currently it's impossible to MERGE object in UPDATE style - i.e. when key is > present in cache, unaffected field values should be retained, and instead of > building new object we should base it on previous one for given key. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7761) EXPLAIN with run time statistics
[ https://issues.apache.org/jira/browse/IGNITE-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7761. --- > EXPLAIN with run time statistics > > > Key: IGNITE-7761 > URL: https://issues.apache.org/jira/browse/IGNITE-7761 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Priority: Major > > For performance tuning of the sql queries It is nice to have actual run time > statistics of the query execution. > Statistics could include elapsed time and the number of rows for each query > node. > Example: > > ||Rows||Actual Time||Plan Node|| || > |1|5ms|group by city|Index scan using person.city| > |20|30ms|person.age=5|Full scan(person.age)| > |131231|50ms|person.name='John'|Index scan using person_name_idx| > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9778) Gathering local node statistics on query level
[ https://issues.apache.org/jira/browse/IGNITE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9778: Labels: iep-29 (was: iep-27) > Gathering local node statistics on query level > -- > > Key: IGNITE-9778 > URL: https://issues.apache.org/jira/browse/IGNITE-9778 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > Should be gathered and exposed IO statistics on SQL query level. It should > contains number of logical and physical read operations. In case query is > distributed then local gathered statistics should contains aggregated stats > from all required node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4149) Consider adding bitmap index to SQL engine.
[ https://issues.apache.org/jira/browse/IGNITE-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4149. - Resolution: Won't Fix The ticket appears to be irrelevant (3 years of inactivity). Will be re-opened if needed. > Consider adding bitmap index to SQL engine. > --- > > Key: IGNITE-4149 > URL: https://issues.apache.org/jira/browse/IGNITE-4149 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.7 >Reporter: Vladimir Ozerov >Priority: Major > Labels: sql-engine > > Bitmap index can help us a lot when there are only several distinct values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6079) SQL: implement base table statistics
[
https://issues.apache.org/jira/browse/IGNITE-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6079:
Description:
Ignite lacks cost-based optimizer what doesn't allow us to build efficient
execution plans. Let's start moving in this direction.
The ticket is about creating local statistics for tables. In the first phase
they will not be shared between nodes, neither they will participate in query
optimization. The ultimate goal of this ticket is to start gathering some info
in the background and provide necessary internal infrastructure and APIs for
that.
*1. API*
Let's start with a single method {{GridQueryProcessor.rebuildStatistics()}},
which will build stats for all existing tables.
Then implement ANALYZE command [1]
*2. Infrastructure*
- Statistics are transient, not persisted
- We need a background worker which will re-build them on regular basis and
replace old with new using copy-on-write approach
- Statistics are created for indexed (i.e. sorted) columns
- Sampling should be used to avoid full table scan
*3. Statistics types*
- Height-based: the whole range is split into N pieces, so that exactly M/N
entries are located between X and X+1 piece, where M is number of records
One statistics type should be enough in the first iteration.
[1] http://h2database.com/html/grammar.html#analyze
was:
Ignite lacks cost-based optimizer what doesn't allow us to build efficient
execution plans. Let's start moving in this direction.
The ticket is about creating local statistics for tables. In the first phase
they will not be shared between nodes, neither they will participate in query
optimization. The ultimate goal of this ticket is to start gathering some info
in the background and provide necessary internal infrastructure and APIs for
that.
*1. API*
Let's start with a single method {{GridQueryProcessor.rebuildStatistics()}},
which will build stats for all existing tables.
*2. Infrastructure*
- Statistics are transient, not persisted
- We need a background worker which will re-build them on regular basis and
replace old with new using copy-on-write approach
- Statistics are created for indexed (i.e. sorted) columns
- Sampling should be used to avoid full table scan
*3. Statistics types*
- Height-based: the whole range is split into N pieces, so that exactly M/N
entries are located between X and X+1 piece, where M is number of records
One statistics type should be enough in the first iteration.
> SQL: implement base table statistics
>
>
> Key: IGNITE-6079
> URL: https://issues.apache.org/jira/browse/IGNITE-6079
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance, sql-engine
>
> Ignite lacks cost-based optimizer what doesn't allow us to build efficient
> execution plans. Let's start moving in this direction.
> The ticket is about creating local statistics for tables. In the first phase
> they will not be shared between nodes, neither they will participate in query
> optimization. The ultimate goal of this ticket is to start gathering some
> info in the background and provide necessary internal infrastructure and APIs
> for that.
> *1. API*
> Let's start with a single method {{GridQueryProcessor.rebuildStatistics()}},
> which will build stats for all existing tables.
> Then implement ANALYZE command [1]
> *2. Infrastructure*
> - Statistics are transient, not persisted
> - We need a background worker which will re-build them on regular basis and
> replace old with new using copy-on-write approach
> - Statistics are created for indexed (i.e. sorted) columns
> - Sampling should be used to avoid full table scan
> *3. Statistics types*
> - Height-based: the whole range is split into N pieces, so that exactly M/N
> entries are located between X and X+1 piece, where M is number of records
> One statistics type should be enough in the first iteration.
> [1] http://h2database.com/html/grammar.html#analyze
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-3171) Support column selectivity calculation for SQL
[ https://issues.apache.org/jira/browse/IGNITE-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3171. --- > Support column selectivity calculation for SQL > -- > > Key: IGNITE-3171 > URL: https://issues.apache.org/jira/browse/IGNITE-3171 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Sergi Vladykin >Priority: Major > > Need to support ANALYZE command. > http://h2database.com/html/grammar.html#analyze > Currently H2 explicitly ignores external table engines (don't see any reasons > why). Probably we have to fix H2 by adding method Table.canAnalyze() and use > it in that check. > Also when IGNITE-1232 will be merged we'll need to propagate this statistics > to clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-3823) Add nested joins support
[ https://issues.apache.org/jira/browse/IGNITE-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3823. - Resolution: Won't Fix The ticket appears to be irrelevant (3 years of inactivity). Will be re-opened if needed. > Add nested joins support > > > Key: IGNITE-3823 > URL: https://issues.apache.org/jira/browse/IGNITE-3823 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.7 >Reporter: Igor Sapego >Priority: Major > Labels: sql-engine > > Currently, nested joins are not supported as well as any other query that get > reduced to the nested join. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-1024) Failed to find SQL Table exception is thrown when indexing is not in the classpath
[
https://issues.apache.org/jira/browse/IGNITE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-1024.
---
> Failed to find SQL Table exception is thrown when indexing is not in the
> classpath
> --
>
> Key: IGNITE-1024
> URL: https://issues.apache.org/jira/browse/IGNITE-1024
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: Usability
>
> When indexing is disabled but user tries to set indexed types, no warning is
> printed and when user tries to run an SQL query, the following exception is
> thrown:
> {{javax.cache.CacheException: Failed to find SQL table for type: MyClass}}
> Ignite should give a proper warning on startup when indexed types are set and
> indexing is not enabled and also throw a correct exception when SQL queries
> are used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-1024) Failed to find SQL Table exception is thrown when indexing is not in the classpath
[
https://issues.apache.org/jira/browse/IGNITE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-1024.
-
Resolution: Fixed
Already fixed.
> Failed to find SQL Table exception is thrown when indexing is not in the
> classpath
> --
>
> Key: IGNITE-1024
> URL: https://issues.apache.org/jira/browse/IGNITE-1024
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: Usability
>
> When indexing is disabled but user tries to set indexed types, no warning is
> printed and when user tries to run an SQL query, the following exception is
> thrown:
> {{javax.cache.CacheException: Failed to find SQL table for type: MyClass}}
> Ignite should give a proper warning on startup when indexed types are set and
> indexing is not enabled and also throw a correct exception when SQL queries
> are used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-3415) UNION query does not remove duplicates
[ https://issues.apache.org/jira/browse/IGNITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3415. - Resolution: Fixed Seems to be already fixed. > UNION query does not remove duplicates > -- > > Key: IGNITE-3415 > URL: https://issues.apache.org/jira/browse/IGNITE-3415 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.6 >Reporter: Semen Boikov >Priority: Major > Labels: sql-splitter > > Looks like UNION query does not remove duplicates on reduce step. > Added test reproducing issue - IgniteCacheUnionDuplicatesTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2906.
-
Resolution: Fixed
The ticket appears to be irrelevant (>2 years of inactivity). Will be re-opened
if needed. The feature is not likely to be implemented, as we are amining
towards flat models as opposed to complex nesting.
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Bug
> Components: cache, data structures, general, sql
>Reporter: Krome Plasma
>Priority: Major
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the enclosing type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id because the names are flattened to simply
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-1140) Find aggregate functions in HAVING clause or rewrite query to put all aggregates to SELECT clause.
[ https://issues.apache.org/jira/browse/IGNITE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-1140. - Resolution: Fixed The ticket appears to be irrelevant (>2 years of inactivity). Will be re-opened if needed. > Find aggregate functions in HAVING clause or rewrite query to put all > aggregates to SELECT clause. > -- > > Key: IGNITE-1140 > URL: https://issues.apache.org/jira/browse/IGNITE-1140 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: sql-splitter > > See TODO in Splitter -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-1141) Check if sorting is done over aggregated expression, otherwise we can sort and use offset-limit.
[ https://issues.apache.org/jira/browse/IGNITE-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-1141. --- > Check if sorting is done over aggregated expression, otherwise we can sort > and use offset-limit. > > > Key: IGNITE-1141 > URL: https://issues.apache.org/jira/browse/IGNITE-1141 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: sql-splitter > > See TODO in splitter -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-1141) Check if sorting is done over aggregated expression, otherwise we can sort and use offset-limit.
[ https://issues.apache.org/jira/browse/IGNITE-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-1141. - Resolution: Fixed The ticket appears to be irrelevant (>2 years of inactivity). Will be re-opened if needed. > Check if sorting is done over aggregated expression, otherwise we can sort > and use offset-limit. > > > Key: IGNITE-1141 > URL: https://issues.apache.org/jira/browse/IGNITE-1141 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: sql-splitter > > See TODO in splitter -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-1140) Find aggregate functions in HAVING clause or rewrite query to put all aggregates to SELECT clause.
[ https://issues.apache.org/jira/browse/IGNITE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-1140. --- > Find aggregate functions in HAVING clause or rewrite query to put all > aggregates to SELECT clause. > -- > > Key: IGNITE-1140 > URL: https://issues.apache.org/jira/browse/IGNITE-1140 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: sql-splitter > > See TODO in Splitter -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2906.
---
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Bug
> Components: cache, data structures, general, sql
>Reporter: Krome Plasma
>Priority: Major
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the enclosing type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id because the names are flattened to simply
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-5371) Persistence for text indices
[ https://issues.apache.org/jira/browse/IGNITE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5371. --- > Persistence for text indices > > > Key: IGNITE-5371 > URL: https://issues.apache.org/jira/browse/IGNITE-5371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.1 >Reporter: Alexei Scherbakov >Priority: Major > > Currently text indices (used with TextQuery) recide in java heap and do not > survive node restarts. With the incoming persistence feature in 2.1 this > behavior is uncceptable. > We need to implement LuceneDirectory based on PageMemory to make indices > persistable and turn Ignite into full fledged full text search engine. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5891) Persistence for geo-spatial indexes
[ https://issues.apache.org/jira/browse/IGNITE-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5891. --- > Persistence for geo-spatial indexes > --- > > Key: IGNITE-5891 > URL: https://issues.apache.org/jira/browse/IGNITE-5891 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Priority: Major > > Similar to IGNITE-5371, but for spatial indexes. Currently they are stored > only in-memory, outside of memory policies. Need to integrate them into a > product from persistence perspective. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5891) Persistence for geo-spatial indexes
[ https://issues.apache.org/jira/browse/IGNITE-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5891. - Resolution: Won't Fix Not relevant at the moment. > Persistence for geo-spatial indexes > --- > > Key: IGNITE-5891 > URL: https://issues.apache.org/jira/browse/IGNITE-5891 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Priority: Major > > Similar to IGNITE-5371, but for spatial indexes. Currently they are stored > only in-memory, outside of memory policies. Need to integrate them into a > product from persistence perspective. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6072) SQL: client node should not hold the whole data set in-memory when possible when merge table is there
[ https://issues.apache.org/jira/browse/IGNITE-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6072. - Resolution: Won't Fix Will be fixed with "lazy" queries separately. Closing this one. > SQL: client node should not hold the whole data set in-memory when possible > when merge table is there > - > > Key: IGNITE-6072 > URL: https://issues.apache.org/jira/browse/IGNITE-6072 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > > We implemented a fix for a case without merge table (IGNITE-6019). Let's try > to do the same for merge table case. Essentially, we need to split all > queries into two groups: > - Blocking - i.e. it require the whole result set from mappers first > - Non-blocking - everything what is not blocking :-) > Fix should be applied only to non-blocking case. Raw estimation from my side, > what is "blocking": > 1) GROUP BY/HAVING > 2) DISTINCT > 3) LIMIT/OFFSET > 4) Subqueries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6072) SQL: client node should not hold the whole data set in-memory when possible when merge table is there
[ https://issues.apache.org/jira/browse/IGNITE-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6072. --- > SQL: client node should not hold the whole data set in-memory when possible > when merge table is there > - > > Key: IGNITE-6072 > URL: https://issues.apache.org/jira/browse/IGNITE-6072 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > > We implemented a fix for a case without merge table (IGNITE-6019). Let's try > to do the same for merge table case. Essentially, we need to split all > queries into two groups: > - Blocking - i.e. it require the whole result set from mappers first > - Non-blocking - everything what is not blocking :-) > Fix should be applied only to non-blocking case. Raw estimation from my side, > what is "blocking": > 1) GROUP BY/HAVING > 2) DISTINCT > 3) LIMIT/OFFSET > 4) Subqueries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6087) SQL: Ability to pass one column to multiple object fields
[
https://issues.apache.org/jira/browse/IGNITE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6087.
-
Resolution: Won't Fix
Not relevant at the moment. Our goal for now is to simplify stuff, instead of
complicating it further.
> SQL: Ability to pass one column to multiple object fields
> -
>
> Key: IGNITE-6087
> URL: https://issues.apache.org/jira/browse/IGNITE-6087
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
>
> Consider the following case:
> {code}
> class PersonKey {
> long id;
> }
> class Person {
> long id;
> String name;
> }
> {code}This is frequent and convenient pattern as it allows to derive a key
> from a value.
> We do not support it in DML at the moment, as column can be mapped only to a
> single object fields. Let's fix it, introducing some new option to
> {{QueryEntity}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6045) Hibernate dialect for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6045. - Resolution: Fixed Not relevant at the moment. Closing due to long period of inactivity. > Hibernate dialect for Ignite > > > Key: IGNITE-6045 > URL: https://issues.apache.org/jira/browse/IGNITE-6045 > Project: Ignite > Issue Type: Task > Components: hibernate, sql >Reporter: Dmitriy Setrakyan >Priority: Major > > Given that we have a very rich SQL support starting with version 2.1, it > makes sense to create an Ignite SQL dialect for Hibernate? > https://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/session-configuration.html#configuration-optional-dialects -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6045) Hibernate dialect for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6045. --- > Hibernate dialect for Ignite > > > Key: IGNITE-6045 > URL: https://issues.apache.org/jira/browse/IGNITE-6045 > Project: Ignite > Issue Type: Task > Components: hibernate, sql >Reporter: Dmitriy Setrakyan >Priority: Major > > Given that we have a very rich SQL support starting with version 2.1, it > makes sense to create an Ignite SQL dialect for Hibernate? > https://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/session-configuration.html#configuration-optional-dialects -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6087) SQL: Ability to pass one column to multiple object fields
[
https://issues.apache.org/jira/browse/IGNITE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6087.
---
> SQL: Ability to pass one column to multiple object fields
> -
>
> Key: IGNITE-6087
> URL: https://issues.apache.org/jira/browse/IGNITE-6087
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
>
> Consider the following case:
> {code}
> class PersonKey {
> long id;
> }
> class Person {
> long id;
> String name;
> }
> {code}This is frequent and convenient pattern as it allows to derive a key
> from a value.
> We do not support it in DML at the moment, as column can be mapped only to a
> single object fields. Let's fix it, introducing some new option to
> {{QueryEntity}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-3171) Support column selectivity calculation for SQL
[ https://issues.apache.org/jira/browse/IGNITE-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3171. - Resolution: Duplicate > Support column selectivity calculation for SQL > -- > > Key: IGNITE-3171 > URL: https://issues.apache.org/jira/browse/IGNITE-3171 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Sergi Vladykin >Priority: Major > > Need to support ANALYZE command. > http://h2database.com/html/grammar.html#analyze > Currently H2 explicitly ignores external table engines (don't see any reasons > why). Probably we have to fix H2 by adding method Table.canAnalyze() and use > it in that check. > Also when IGNITE-1232 will be merged we'll need to propagate this statistics > to clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5962) Increase max length of index name
[ https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767969#comment-16767969 ] Vladimir Ozerov commented on IGNITE-5962: - Instead of increasing index name I'd rather propose to make sure that correct exceptions are thrown. We need to make sure that this is the case for both indexes created on startup, and indexes created on dynamic table or index create commands. > Increase max length of index name > - > > Key: IGNITE-5962 > URL: https://issues.apache.org/jira/browse/IGNITE-5962 > Project: Ignite > Issue Type: Improvement > Components: general, sql >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Pavel Kuznetsov >Priority: Major > > In https://issues.apache.org/jira/browse/IGNITE-5941 max index name length > was reduced from 768 to 256 bytes. If we need to support longer names, we > need to change format of metastore data pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11318) Web console: add viewport meta tag
Ilya Borisov created IGNITE-11318: - Summary: Web console: add viewport meta tag Key: IGNITE-11318 URL: https://issues.apache.org/jira/browse/IGNITE-11318 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Web console does not scale automatically on mobile devices, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6298) SQL: Print names of created tables on node startup
[
https://issues.apache.org/jira/browse/IGNITE-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6298:
Priority: Blocker (was: Major)
> SQL: Print names of created tables on node startup
> --
>
> Key: IGNITE-6298
> URL: https://issues.apache.org/jira/browse/IGNITE-6298
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Blocker
> Labels: usability
>
> Currently no information about created database objects are printed to the
> log. It might be very hard to understand what tables and indexes were created
> in response to processing of provided {{QueryEntity}}-es.
> We should print in the log the following information:
> 1) Created tables with their columns
> 2) Created indexes
> Alternatively, may be it would be enough to print executed SQL statements!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-5371) Persistence for text indices
[ https://issues.apache.org/jira/browse/IGNITE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5371. - Resolution: Won't Fix Not relevant at the moment. > Persistence for text indices > > > Key: IGNITE-5371 > URL: https://issues.apache.org/jira/browse/IGNITE-5371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.1 >Reporter: Alexei Scherbakov >Priority: Major > > Currently text indices (used with TextQuery) recide in java heap and do not > survive node restarts. With the incoming persistence feature in 2.1 this > behavior is uncceptable. > We need to implement LuceneDirectory based on PageMemory to make indices > persistable and turn Ignite into full fledged full text search engine. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11318) Web console: add viewport meta tag
[ https://issues.apache.org/jira/browse/IGNITE-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11318: -- Attachment: no viewport meta tag.png > Web console: add viewport meta tag > -- > > Key: IGNITE-11318 > URL: https://issues.apache.org/jira/browse/IGNITE-11318 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > Attachments: no viewport meta tag.png > > > Web console does not scale automatically on mobile devices, so I propose to > add [viewport meta > tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-3415) UNION query does not remove duplicates
[ https://issues.apache.org/jira/browse/IGNITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3415. --- > UNION query does not remove duplicates > -- > > Key: IGNITE-3415 > URL: https://issues.apache.org/jira/browse/IGNITE-3415 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.6 >Reporter: Semen Boikov >Priority: Major > Labels: sql-splitter > > Looks like UNION query does not remove duplicates on reduce step. > Added test reproducing issue - IgniteCacheUnionDuplicatesTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11318) Web console: add viewport meta tag
[ https://issues.apache.org/jira/browse/IGNITE-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11318: -- Description: Web console does not scale automatically on mobile devices, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. Profile screen without the tag: !no viewport meta tag.png! With viewport meta tag: !with tag.png! was:Web console does not scale automatically on mobile devices, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. > Web console: add viewport meta tag > -- > > Key: IGNITE-11318 > URL: https://issues.apache.org/jira/browse/IGNITE-11318 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > Attachments: no viewport meta tag.png, with tag.png > > > Web console does not scale automatically on mobile devices, so I propose to > add [viewport meta > tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. > Profile screen without the tag: > !no viewport meta tag.png! > With viewport meta tag: > !with tag.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6298) SQL: Print names of created tables on node startup
[
https://issues.apache.org/jira/browse/IGNITE-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767971#comment-16767971
]
Vladimir Ozerov commented on IGNITE-6298:
-
In addition we must print names of columns, indexes, etc. May be it makes sense
even to print actual commands.
> SQL: Print names of created tables on node startup
> --
>
> Key: IGNITE-6298
> URL: https://issues.apache.org/jira/browse/IGNITE-6298
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Blocker
> Labels: usability
>
> Currently no information about created database objects are printed to the
> log. It might be very hard to understand what tables and indexes were created
> in response to processing of provided {{QueryEntity}}-es.
> We should print in the log the following information:
> 1) Created tables with their columns
> 2) Created indexes
> Alternatively, may be it would be enough to print executed SQL statements!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5962) Increase max length of index name
[ https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-5962: --- Assignee: Pavel Kuznetsov > Increase max length of index name > - > > Key: IGNITE-5962 > URL: https://issues.apache.org/jira/browse/IGNITE-5962 > Project: Ignite > Issue Type: Improvement > Components: general, sql >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Pavel Kuznetsov >Priority: Major > > In https://issues.apache.org/jira/browse/IGNITE-5941 max index name length > was reduced from 768 to 256 bytes. If we need to support longer names, we > need to change format of metastore data pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11318) Web console: add viewport meta tag
[ https://issues.apache.org/jira/browse/IGNITE-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11318: -- Attachment: with tag.png > Web console: add viewport meta tag > -- > > Key: IGNITE-11318 > URL: https://issues.apache.org/jira/browse/IGNITE-11318 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > Attachments: no viewport meta tag.png, with tag.png > > > Web console does not scale automatically on mobile devices, so I propose to > add [viewport meta > tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-6199) SQL: DML processor should send deltas instead of full values when possible
[ https://issues.apache.org/jira/browse/IGNITE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reopened IGNITE-6199: - > SQL: DML processor should send deltas instead of full values when possible > -- > > Key: IGNITE-6199 > URL: https://issues.apache.org/jira/browse/IGNITE-6199 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > Currently we send full values during DML operations. Instead, we should find > the way to send only changed attributes. Chances that it will require adding > versions of existing entries, or even the whole MVCC, to prevent inconsistent > updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6275) SQL: Get rid of IGNITE_SQL_MERGE_TABLE_MAX_SIZE system property
[
https://issues.apache.org/jira/browse/IGNITE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6275.
-
Resolution: Won't Fix
Not relevant at the moment. Will be re-opened if needed.
> SQL: Get rid of IGNITE_SQL_MERGE_TABLE_MAX_SIZE system property
> ---
>
> Key: IGNITE-6275
> URL: https://issues.apache.org/jira/browse/IGNITE-6275
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: usability
>
> This property has very unclear semantics and normally user should never
> bother about it. We need to review {{GridMergeIndex}} and try to get rid of
> both {{IGNITE_SQL_MERGE_TABLE_MAX_SIZE}} and
> {{IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE}} completely.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6199) SQL: DML processor should send deltas instead of full values when possible
[ https://issues.apache.org/jira/browse/IGNITE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6199. - Resolution: Won't Fix Not relevant at the moment. Will be re-opened if needed. > SQL: DML processor should send deltas instead of full values when possible > -- > > Key: IGNITE-6199 > URL: https://issues.apache.org/jira/browse/IGNITE-6199 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > Currently we send full values during DML operations. Instead, we should find > the way to send only changed attributes. Chances that it will require adding > versions of existing entries, or even the whole MVCC, to prevent inconsistent > updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6266) Nested BinaryObject fields cannot be inserted via SQL
[ https://issues.apache.org/jira/browse/IGNITE-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6266. --- > Nested BinaryObject fields cannot be inserted via SQL > - > > Key: IGNITE-6266 > URL: https://issues.apache.org/jira/browse/IGNITE-6266 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Alexandr Fedotov >Priority: Major > Attachments: BinaryObjectNestedFieldsQueryTest.java > > > SQL insert of nested BinaryObject fields triggers an assertion if assertions > are enabled. > java.lang.AssertionError > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:474) > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:538) > at > org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:140) > at > org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:159) > at > org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.setValue(QueryTypeDescriptorImpl.java:203) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:944) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:812) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:406) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:190) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:224) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1350) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1805) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1803) > at > org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2283) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1810) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:609) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:584) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382) > at > org.apache.ignite.internal.processors.cache.BinaryObjectNestedFieldsQueryTest.testNestedFieldsCanBeInserted(BinaryObjectNestedFieldsQueryTest.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at junit.framework.TestCase.runTest(TestCase.java:176) > When assertions are disabled an exception is thrown > Caused by: java.lang.UnsupportedOperationException: Individual properties can > be set for binary builders only > at > org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:173) > at > org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.setValue(QueryTypeDescriptorImpl.java:203) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:944) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:812) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:406) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:190) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:224) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1350) > at > org.apache.ignite.internal.processors.que
[jira] [Closed] (IGNITE-6275) SQL: Get rid of IGNITE_SQL_MERGE_TABLE_MAX_SIZE system property
[
https://issues.apache.org/jira/browse/IGNITE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6275.
---
> SQL: Get rid of IGNITE_SQL_MERGE_TABLE_MAX_SIZE system property
> ---
>
> Key: IGNITE-6275
> URL: https://issues.apache.org/jira/browse/IGNITE-6275
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: usability
>
> This property has very unclear semantics and normally user should never
> bother about it. We need to review {{GridMergeIndex}} and try to get rid of
> both {{IGNITE_SQL_MERGE_TABLE_MAX_SIZE}} and
> {{IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE}} completely.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6265) BinaryObject fields nested deeper than one level cannot be updated via SQL
[
https://issues.apache.org/jira/browse/IGNITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6265.
-
Resolution: Won't Fix
Not relevant at the moment. Will be re-opened if needed.
> BinaryObject fields nested deeper than one level cannot be updated via SQL
> --
>
> Key: IGNITE-6265
> URL: https://issues.apache.org/jira/browse/IGNITE-6265
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Priority: Major
> Attachments: BinaryObjectNestedFieldsQueryTest.java
>
>
> SQL update of a BinaryObject field nested deeper than one level throws an
> exception
> Caused by: class org.apache.ignite.IgniteCheckedException: Non-binary object
> received as a result of property extraction
> [parent=org.apache.ignite.internal.processors.query.property.QueryBinaryProperty@1e86486b,
> propName=nestedObj,
> obj=org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl@1fc7875]
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:105)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:159)
> at
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.setColumnValue(H2RowDescriptor.java:348)
> The problem is that only a BinaryObject is expected in the following part of
> the {{QueryBinaryProperty.value}} method
> {code:java}
> if (!ctx.cacheObjects().isBinaryObject(obj))
> throw new IgniteCheckedException("Non-binary object received as a result
> of property extraction " + "[parent=" + parent + ", propName=" + propName +
> ", obj=" + obj + ']');
> {code}
> Corresponding SQL CRUD tests should be added for the nested BinaryObjects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6199) SQL: DML processor should send deltas instead of full values when possible
[ https://issues.apache.org/jira/browse/IGNITE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6199. - Resolution: Fixed Not relevant at the moment. Will be re-opened if needed. > SQL: DML processor should send deltas instead of full values when possible > -- > > Key: IGNITE-6199 > URL: https://issues.apache.org/jira/browse/IGNITE-6199 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > Currently we send full values during DML operations. Instead, we should find > the way to send only changed attributes. Chances that it will require adding > versions of existing entries, or even the whole MVCC, to prevent inconsistent > updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6265) BinaryObject fields nested deeper than one level cannot be updated via SQL
[
https://issues.apache.org/jira/browse/IGNITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6265.
---
> BinaryObject fields nested deeper than one level cannot be updated via SQL
> --
>
> Key: IGNITE-6265
> URL: https://issues.apache.org/jira/browse/IGNITE-6265
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Priority: Major
> Attachments: BinaryObjectNestedFieldsQueryTest.java
>
>
> SQL update of a BinaryObject field nested deeper than one level throws an
> exception
> Caused by: class org.apache.ignite.IgniteCheckedException: Non-binary object
> received as a result of property extraction
> [parent=org.apache.ignite.internal.processors.query.property.QueryBinaryProperty@1e86486b,
> propName=nestedObj,
> obj=org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl@1fc7875]
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:105)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:159)
> at
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.setColumnValue(H2RowDescriptor.java:348)
> The problem is that only a BinaryObject is expected in the following part of
> the {{QueryBinaryProperty.value}} method
> {code:java}
> if (!ctx.cacheObjects().isBinaryObject(obj))
> throw new IgniteCheckedException("Non-binary object received as a result
> of property extraction " + "[parent=" + parent + ", propName=" + propName +
> ", obj=" + obj + ']');
> {code}
> Corresponding SQL CRUD tests should be added for the nested BinaryObjects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6266) Nested BinaryObject fields cannot be inserted via SQL
[ https://issues.apache.org/jira/browse/IGNITE-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6266. - Resolution: Won't Fix Not relevant at the moment. Will be re-opened if needed. > Nested BinaryObject fields cannot be inserted via SQL > - > > Key: IGNITE-6266 > URL: https://issues.apache.org/jira/browse/IGNITE-6266 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Alexandr Fedotov >Priority: Major > Attachments: BinaryObjectNestedFieldsQueryTest.java > > > SQL insert of nested BinaryObject fields triggers an assertion if assertions > are enabled. > java.lang.AssertionError > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:474) > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:538) > at > org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:140) > at > org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:159) > at > org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.setValue(QueryTypeDescriptorImpl.java:203) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:944) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:812) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:406) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:190) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:224) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1350) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1805) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1803) > at > org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2283) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1810) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:609) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:584) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382) > at > org.apache.ignite.internal.processors.cache.BinaryObjectNestedFieldsQueryTest.testNestedFieldsCanBeInserted(BinaryObjectNestedFieldsQueryTest.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at junit.framework.TestCase.runTest(TestCase.java:176) > When assertions are disabled an exception is thrown > Caused by: java.lang.UnsupportedOperationException: Individual properties can > be set for binary builders only > at > org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.setValue(QueryBinaryProperty.java:173) > at > org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.setValue(QueryTypeDescriptorImpl.java:203) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:944) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:812) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:406) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:190) > at > org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:224) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFi
[jira] [Updated] (IGNITE-11318) Web console: add viewport meta tag
[ https://issues.apache.org/jira/browse/IGNITE-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11318: -- Description: Web console does not scale automatically on tablets, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. Obviously, all the screens will have to be updated to look better in narrow viewports. Profile screen without the tag: !no viewport meta tag.png! With viewport meta tag: !with tag.png! was: Web console does not scale automatically on tablets, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. Profile screen without the tag: !no viewport meta tag.png! With viewport meta tag: !with tag.png! > Web console: add viewport meta tag > -- > > Key: IGNITE-11318 > URL: https://issues.apache.org/jira/browse/IGNITE-11318 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > Attachments: no viewport meta tag.png, with tag.png > > > Web console does not scale automatically on tablets, so I propose to add > [viewport meta > tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. > Obviously, all the screens will have to be updated to look better in narrow > viewports. > Profile screen without the tag: > !no viewport meta tag.png! > With viewport meta tag: > !with tag.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11318) Web console: add viewport meta tag
[ https://issues.apache.org/jira/browse/IGNITE-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11318: -- Description: Web console does not scale automatically on tablets, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. Profile screen without the tag: !no viewport meta tag.png! With viewport meta tag: !with tag.png! was: Web console does not scale automatically on mobile devices, so I propose to add [viewport meta tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. Profile screen without the tag: !no viewport meta tag.png! With viewport meta tag: !with tag.png! > Web console: add viewport meta tag > -- > > Key: IGNITE-11318 > URL: https://issues.apache.org/jira/browse/IGNITE-11318 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > Attachments: no viewport meta tag.png, with tag.png > > > Web console does not scale automatically on tablets, so I propose to add > [viewport meta > tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. > Profile screen without the tag: > !no viewport meta tag.png! > With viewport meta tag: > !with tag.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11310) SQL: Remove special interaction between query parallelism and distributed joins
[
https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767986#comment-16767986
]
Ignite TC Bot commented on IGNITE-11310:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3079497]]
* exe: ExamplesTest.TestRemoteNodesClientMode(SqlDmlExample) - 0,0% fails in
last 379 master runs.
{color:#d04437}Platform .NET{color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=3079493]]
* exe: CacheLinqTest.TestRemoveAll - 0,0% fails in last 580 master runs.
* exe: CacheLinqTest.TestRemoveAll - 0,0% fails in last 580 master runs.
* exe: CacheLinqTest.TestRemoveAll - 0,0% fails in last 580 master runs.
{color:#d04437}Queries 1{color} [[tests
46|https://ci.ignite.apache.org/viewLog.html?buildId=3079499]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testUpdateSetTableSubquery - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
H2DynamicColumnsServerBasicSelfTest.testComplexOperations - 0,0% fails in last
412 master runs.
* IgniteBinaryCacheQueryTestSuite:
GridCacheDynamicLoadOnClientTest.testClientJdbcUpdate - 0,0% fails in last 412
master runs.
* IgniteBinaryCacheQueryTestSuite:
H2DynamicColumnsClientBasicSelfTest.testComplexOperations - 0,0% fails in last
412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheMergeSqlQuerySelfTest.testMergeFromSubquery - 0,0% fails in last 412
master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSegmentedIndexMultiNodeSelfTest.testSegmentedIndex - 0,0% fails in
last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
GridCacheDynamicLoadOnClientPersistentTest.testClientJdbcUpdate - 0,0% fails in
last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testInsertFromSelectGroupBy - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
GridCacheCrossCacheQuerySelfTest.testMultiStatement - 0,0% fails in last 412
master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testNotNullCheckDmlInsertFromSelect - 0,0% fails
in last 411 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testDeleteTop - 0,0% fails in last
412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSegmentedIndexSelfTest.testSegmentedIndex - 0,0% fails in last 412
master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testNotNullCheckDmlUpdateValues - 0,0% fails in
last 411 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testInsertFromSelectUnion - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testUpdateWhereSubquery - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testDeleteWhereSubquery - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
H2DynamicColumnsServerCoordinatorBasicSelfTest.testComplexOperations - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testUpdateSetSubquery - 0,0% fails
in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testInsertFromSelectJoin - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlKeyValueFieldsTest.testKeyValueAlias - 0,0% fails in last 412 master
runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testDelete - 0,0% fails in last 412
master runs.
* IgniteBinaryCacheQueryTestSuite:
H2DynamicIndexingComplexClientAtomicPartitionedTest.testOperations - 0,0% fails
in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testNotNullCheckDmlUpdateFromSelect - 0,0% fails
in last 411 master runs.
* IgniteBinaryCacheQueryTestSuite:
H2DynamicIndexingComplexClientAtomicReplicatedTest.testOperations - 0,0% fails
in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testInsertFromSelect - 0,0% fails
in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testMergeFromSelectJoin - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
H2DynamicIndexingComplexClientTransactionalPartitionedTest.testOperations -
0,0% fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testMergeFromSelectOrderBy - 0,0%
fails in last 412 master runs.
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testInsertFromSelectOrder
[jira] [Closed] (IGNITE-6199) SQL: DML processor should send deltas instead of full values when possible
[ https://issues.apache.org/jira/browse/IGNITE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6199. --- > SQL: DML processor should send deltas instead of full values when possible > -- > > Key: IGNITE-6199 > URL: https://issues.apache.org/jira/browse/IGNITE-6199 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > Currently we send full values during DML operations. Instead, we should find > the way to send only changed attributes. Chances that it will require adding > versions of existing entries, or even the whole MVCC, to prevent inconsistent > updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage
[ https://issues.apache.org/jira/browse/IGNITE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6518. - Resolution: Fixed Not relevant at the moment. Will be re-opened if needed. > Smarter analysis of INSERT and MERGE statements at parsing stage > > > Key: IGNITE-6518 > URL: https://issues.apache.org/jira/browse/IGNITE-6518 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Priority: Major > > We could analyze INSERT and MERGE statements to detect that they don't > specify data for key and/or value to notify users early that their query > can't be executed within Ignite - prior to building plans and attempting to > actually do anything. > (Note how we check that CREATE TABLE doesn't declare columns for key - logic > here would be similar.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage
[ https://issues.apache.org/jira/browse/IGNITE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6518. --- > Smarter analysis of INSERT and MERGE statements at parsing stage > > > Key: IGNITE-6518 > URL: https://issues.apache.org/jira/browse/IGNITE-6518 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Priority: Major > > We could analyze INSERT and MERGE statements to detect that they don't > specify data for key and/or value to notify users early that their query > can't be executed within Ignite - prior to building plans and attempting to > actually do anything. > (Note how we check that CREATE TABLE doesn't declare columns for key - logic > here would be similar.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6296) SQL: Get rid of "collocated" flag
[ https://issues.apache.org/jira/browse/IGNITE-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6296. --- > SQL: Get rid of "collocated" flag > - > > Key: IGNITE-6296 > URL: https://issues.apache.org/jira/browse/IGNITE-6296 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: usability > > This flag forces our execution engine to perform aggregations on mapper nodes > rather than on reducer. > First, we already have enough information in runtime to decide whether we can > optimize or not. Second, if query is complex enough, users would have hard > time trying to figure whether query would return correct result or not. We > should never ever return invalid results. > Let's make our engine smarter, so that it is able to determine whether such > grouping is safe or not and then deprecate that flag. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6296) SQL: Get rid of "collocated" flag
[ https://issues.apache.org/jira/browse/IGNITE-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6296. - Resolution: Won't Fix Will be fixed in the scope of global splitter redesign activity. Closing for now. > SQL: Get rid of "collocated" flag > - > > Key: IGNITE-6296 > URL: https://issues.apache.org/jira/browse/IGNITE-6296 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: usability > > This flag forces our execution engine to perform aggregations on mapper nodes > rather than on reducer. > First, we already have enough information in runtime to decide whether we can > optimize or not. Second, if query is complex enough, users would have hard > time trying to figure whether query would return correct result or not. We > should never ever return invalid results. > Let's make our engine smarter, so that it is able to determine whether such > grouping is safe or not and then deprecate that flag. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6755) Add possibility to create sql tables with DDL without defined PRIMARY KEY, by adding it implicitly
[ https://issues.apache.org/jira/browse/IGNITE-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6755. - Resolution: Won't Fix Not relevant at the moment. Will be re-opened if needed. > Add possibility to create sql tables with DDL without defined PRIMARY KEY, by > adding it implicitly > -- > > Key: IGNITE-6755 > URL: https://issues.apache.org/jira/browse/IGNITE-6755 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6755) Add possibility to create sql tables with DDL without defined PRIMARY KEY, by adding it implicitly
[ https://issues.apache.org/jira/browse/IGNITE-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6755. --- > Add possibility to create sql tables with DDL without defined PRIMARY KEY, by > adding it implicitly > -- > > Key: IGNITE-6755 > URL: https://issues.apache.org/jira/browse/IGNITE-6755 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6918) SQL: support window functions
[
https://issues.apache.org/jira/browse/IGNITE-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6918.
---
> SQL: support window functions
> -
>
> Key: IGNITE-6918
> URL: https://issues.apache.org/jira/browse/IGNITE-6918
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
>
> E.g. {{PARTITION ... OVER}}. Design is to be defined. See [1] as a starting
> point.
> [1] https://en.wikipedia.org/wiki/SQL_window_function
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-6883) Distributed sub-query support
[
https://issues.apache.org/jira/browse/IGNITE-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6883.
---
> Distributed sub-query support
> -
>
> Key: IGNITE-6883
> URL: https://issues.apache.org/jira/browse/IGNITE-6883
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Alin Andrei Corodescu
>Priority: Minor
>
> Include behaviour similar to the distributedJoins flag for inner queries as
> well (gather data from multiple nodes).
> At the moment sub queries are run on remote nodes without being split into
> map and reduce parts and without taking into account data residing in other
> nodes (sometimes collocation is not possible).
> One use case when results are affected by this behaviour is when the subquery
> contains a {code:sql}HAVING{code} clause, since the conditions can filter out
> groups for which not all the entries are on the same node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-6877) Improve behaviour for non-correlated subqueries
[ https://issues.apache.org/jira/browse/IGNITE-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6877. --- > Improve behaviour for non-correlated subqueries > --- > > Key: IGNITE-6877 > URL: https://issues.apache.org/jira/browse/IGNITE-6877 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Alin Andrei Corodescu >Priority: Minor > > Ignite behaves poorly in terms of performance when given queries which > contain IN or = operators followed by a non-correlated subquery. My guess is > that the query is actually run for each row of the table in order to test the > condition. > A possible solution is to store the results of the subquery in a temporary > table, and use it from there. > A workaround at the moment is to use joins instead of IN or = operators, but > this makes the query much more complicated. > Example: > SELECT name > FROM Employees > WHERE age IN (SELECT age FROM Customers) > The performance of this query is very slow for small amounts of data (about > 20 seconds for 4000 rows in each table last time I tried) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6883) Distributed sub-query support
[
https://issues.apache.org/jira/browse/IGNITE-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6883.
-
Resolution: Won't Fix
Closing due to long inactivity. Distributed joins logic is to be redesigned
soon, so tickets will be created as needed.
> Distributed sub-query support
> -
>
> Key: IGNITE-6883
> URL: https://issues.apache.org/jira/browse/IGNITE-6883
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Alin Andrei Corodescu
>Priority: Minor
>
> Include behaviour similar to the distributedJoins flag for inner queries as
> well (gather data from multiple nodes).
> At the moment sub queries are run on remote nodes without being split into
> map and reduce parts and without taking into account data residing in other
> nodes (sometimes collocation is not possible).
> One use case when results are affected by this behaviour is when the subquery
> contains a {code:sql}HAVING{code} clause, since the conditions can filter out
> groups for which not all the entries are on the same node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6877) Improve behaviour for non-correlated subqueries
[ https://issues.apache.org/jira/browse/IGNITE-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6877. - Resolution: Fixed Closing due to long inactivity. Planned logic is to be redesigned soon, so tickets will be created as needed. > Improve behaviour for non-correlated subqueries > --- > > Key: IGNITE-6877 > URL: https://issues.apache.org/jira/browse/IGNITE-6877 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Alin Andrei Corodescu >Priority: Minor > > Ignite behaves poorly in terms of performance when given queries which > contain IN or = operators followed by a non-correlated subquery. My guess is > that the query is actually run for each row of the table in order to test the > condition. > A possible solution is to store the results of the subquery in a temporary > table, and use it from there. > A workaround at the moment is to use joins instead of IN or = operators, but > this makes the query much more complicated. > Example: > SELECT name > FROM Employees > WHERE age IN (SELECT age FROM Customers) > The performance of this query is very slow for small amounts of data (about > 20 seconds for 4000 rows in each table last time I tried) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6771) Insert query failed if kye field is present in value fields
[
https://issues.apache.org/jira/browse/IGNITE-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6771.
-
Resolution: Won't Fix
This behavior is not going to be changed for now.
> Insert query failed if kye field is present in value fields
> ---
>
> Key: IGNITE-6771
> URL: https://issues.apache.org/jira/browse/IGNITE-6771
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.2
>Reporter: Pavel Konstantinov
>Priority: Minor
>
> I'm imported model from DB where a table hasn't a primary key.
> Then using web console I added key field manually (the first field in the
> table).
> Note:
> {code}
>
> {code}
> Then I generated the project and started one server node.
> I'm opened query in web console and tried to execute insert query
> and got an error
> {code}
> ...duplicate field
> {code}
> The issue disappeared only after I removed the same field from value fields.
> I guess it is possible to handle that automatically in POJO logic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-6409) SQL: bypass H2 during index update
[
https://issues.apache.org/jira/browse/IGNITE-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6409.
---
> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance
>
> Currently the only way to update standard user index is through H2
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update
> we have to construct a kind of H2 row which will be passed to index. This
> operation might require unnecessary memory copying and deserializations. We
> should try to find a way to bypass H2 stuff altogether and add data to
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes
> ({{InlineIndexHelper}}, {{H2*IO}}).
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}}
> instead of {{SearchRow}}
> 3) Refactored classes should be moved to core module.
> 4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when
> it is really needed.
> 5) Two operations {{putNative}} and {{getNative}} should be added to
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of
> H2 rows.
> 6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}})
> should be moved to {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward
> compatibility.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6918) SQL: support window functions
[
https://issues.apache.org/jira/browse/IGNITE-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6918.
-
Resolution: Won't Fix
Not relevant at the moment. Will be re-opened if needed.
> SQL: support window functions
> -
>
> Key: IGNITE-6918
> URL: https://issues.apache.org/jira/browse/IGNITE-6918
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
>
> E.g. {{PARTITION ... OVER}}. Design is to be defined. See [1] as a starting
> point.
> [1] https://en.wikipedia.org/wiki/SQL_window_function
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-4757) SQL Query Metrics
[
https://issues.apache.org/jira/browse/IGNITE-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-4757.
-
Resolution: Won't Fix
This will be implemented gradually as a part of IEP-29.
> SQL Query Metrics
> -
>
> Key: IGNITE-4757
> URL: https://issues.apache.org/jira/browse/IGNITE-4757
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Denis Magda
>Priority: Major
>
> SQL queries monitoring part has to be improved. Suggest adding the metrics
> below.
> Per-query metrics. Total history size is defined by
> {{CacheConfiguration.getQueryDetailMetricsSize()}}:
> * Total query execution count.
> * Query execution time - min, max, avg. Provide a breakdown for map, per-join
> and reduce phases.
> * A number of bytes exchanged between nodes during query execution. Provide a
> per-join, unions, etc. breakdown.
> * A number rows returned - min, max, avg.
> * Collocated or non-collocated query.
> In addition, we need to introduce a way to filter out metrics for queries
> that complete faster than some predefined NNN time.
> Finally, research a possibility to put the metrics into the H2 execution
> plan. Create a separated ticket if this task in not completed under this
> ticket.
> Discussion on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Additional-SQL-metrics-td14945.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11318) Web console: add viewport meta tag
[ https://issues.apache.org/jira/browse/IGNITE-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11318: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) [~kuaw26] please review. > Web console: add viewport meta tag > -- > > Key: IGNITE-11318 > URL: https://issues.apache.org/jira/browse/IGNITE-11318 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: no viewport meta tag.png, with tag.png > > Time Spent: 10m > Remaining Estimate: 0h > > Web console does not scale automatically on tablets, so I propose to add > [viewport meta > tag|https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag]. > Obviously, all the screens will have to be updated to look better in narrow > viewports. > Profile screen without the tag: > !no viewport meta tag.png! > With viewport meta tag: > !with tag.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6409) SQL: bypass H2 during index update
[
https://issues.apache.org/jira/browse/IGNITE-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-6409.
-
Resolution: Fixed
Not relevant at the moment.
> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance
>
> Currently the only way to update standard user index is through H2
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update
> we have to construct a kind of H2 row which will be passed to index. This
> operation might require unnecessary memory copying and deserializations. We
> should try to find a way to bypass H2 stuff altogether and add data to
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes
> ({{InlineIndexHelper}}, {{H2*IO}}).
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}}
> instead of {{SearchRow}}
> 3) Refactored classes should be moved to core module.
> 4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when
> it is really needed.
> 5) Two operations {{putNative}} and {{getNative}} should be added to
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of
> H2 rows.
> 6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}})
> should be moved to {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward
> compatibility.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-6771) Insert query failed if kye field is present in value fields
[
https://issues.apache.org/jira/browse/IGNITE-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6771.
---
> Insert query failed if kye field is present in value fields
> ---
>
> Key: IGNITE-6771
> URL: https://issues.apache.org/jira/browse/IGNITE-6771
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.2
>Reporter: Pavel Konstantinov
>Priority: Minor
>
> I'm imported model from DB where a table hasn't a primary key.
> Then using web console I added key field manually (the first field in the
> table).
> Note:
> {code}
>
> {code}
> Then I generated the project and started one server node.
> I'm opened query in web console and tried to execute insert query
> and got an error
> {code}
> ...duplicate field
> {code}
> The issue disappeared only after I removed the same field from value fields.
> I guess it is possible to handle that automatically in POJO logic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7370) Drop test tables in each test case in H2DynamicTableSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-7370.
---
> Drop test tables in each test case in H2DynamicTableSelfTest
>
>
> Key: IGNITE-7370
> URL: https://issues.apache.org/jira/browse/IGNITE-7370
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Minor
>
> Failing test cases are leaving tables they've created which in turn causes
> subsequent test cases to report false failures, e.g. when the latter test
> case tries to create a table with the same name.
> It would be great for such tables tables to run down curtain and join the
> choir invisible in finally clause; an example:
> {noformat}
> public void testInternalCreateExistingTable() throws Exception {
> + try {
> execute("CREATE TABLE \"Person\" (\"id\" int, \"city\"
> varchar," +
> " \"name\" varchar, \"surname\" varchar, \"age\" int,
> PRIMARY KEY (\"id\", \"city\")) " +
> "template=\"cache\"");
> GridTestUtils.assertThrows(null, new Callable() {
> @Override public Object call() throws Exception {
> execute("CREATE TABLE \"Person\" (\"id\" int,
> \"city\" varchar" +
> ", \"name\" varchar, \"surname\" varchar,
> \"age\" int, PRIMARY KEY (\"id\", \"city\")) " +
> "template=\"cache\"");
> return null;
> }
> }, IgniteSQLException.class, "Table already exists:
> Person");
> + }
> + finally {
> + execute("DROP TABLE \"Person\"");
> + }
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7373) Fix style guide violations and imprecise naming in SqlParser-related code
[ https://issues.apache.org/jira/browse/IGNITE-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7373. - Resolution: Won't Fix Not relevant. > Fix style guide violations and imprecise naming in SqlParser-related code > - > > Key: IGNITE-7373 > URL: https://issues.apache.org/jira/browse/IGNITE-7373 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Minor > > SQL parser implementation contains many abbreviation rule violations and > names that doesn't reflect the method intention: > 1. "token" instead of "tok" in variables > 2. SqlParserUtils.skipIfMatches throws an exception if the token doesn't > match, although the name doesn't reflect this. 'accept' or 'skip' without > 'if' would be more precise > 3. SqlKeyword.DEFAULT clashes with SqlParserTokenType.DEFAULT > 4. SqlParserUtils.skipCommaOrRightParenthesis() can be generalized. It's > better to return the token it's met instead of obscure boolean (otherwise the > name should reflect the returned type) > 5. It makes sense to have a method to return the current token. The container > can be refactored from SqlLexerLookAheadToken, since lookahead token doesn't > need it's own class. > 6. SqlLexerTokenType.EOF does not mean 'end of FILE'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6942) Auto re-connect to other node in case of failure of current
[ https://issues.apache.org/jira/browse/IGNITE-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6942. --- > Auto re-connect to other node in case of failure of current > --- > > Key: IGNITE-6942 > URL: https://issues.apache.org/jira/browse/IGNITE-6942 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Mikhail Cherkasov >Priority: Major > > it will be great to have a re-connect feature for thin driver, in case if > server failure it should choose another server node from a list of server > nods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7370) Drop test tables in each test case in H2DynamicTableSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-7370.
-
Resolution: Won't Fix
Not relevant.
> Drop test tables in each test case in H2DynamicTableSelfTest
>
>
> Key: IGNITE-7370
> URL: https://issues.apache.org/jira/browse/IGNITE-7370
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Priority: Minor
>
> Failing test cases are leaving tables they've created which in turn causes
> subsequent test cases to report false failures, e.g. when the latter test
> case tries to create a table with the same name.
> It would be great for such tables tables to run down curtain and join the
> choir invisible in finally clause; an example:
> {noformat}
> public void testInternalCreateExistingTable() throws Exception {
> + try {
> execute("CREATE TABLE \"Person\" (\"id\" int, \"city\"
> varchar," +
> " \"name\" varchar, \"surname\" varchar, \"age\" int,
> PRIMARY KEY (\"id\", \"city\")) " +
> "template=\"cache\"");
> GridTestUtils.assertThrows(null, new Callable() {
> @Override public Object call() throws Exception {
> execute("CREATE TABLE \"Person\" (\"id\" int,
> \"city\" varchar" +
> ", \"name\" varchar, \"surname\" varchar,
> \"age\" int, PRIMARY KEY (\"id\", \"city\")) " +
> "template=\"cache\"");
> return null;
> }
> }, IgniteSQLException.class, "Table already exists:
> Person");
> + }
> + finally {
> + execute("DROP TABLE \"Person\"");
> + }
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7373) Fix style guide violations and imprecise naming in SqlParser-related code
[ https://issues.apache.org/jira/browse/IGNITE-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7373. --- > Fix style guide violations and imprecise naming in SqlParser-related code > - > > Key: IGNITE-7373 > URL: https://issues.apache.org/jira/browse/IGNITE-7373 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Minor > > SQL parser implementation contains many abbreviation rule violations and > names that doesn't reflect the method intention: > 1. "token" instead of "tok" in variables > 2. SqlParserUtils.skipIfMatches throws an exception if the token doesn't > match, although the name doesn't reflect this. 'accept' or 'skip' without > 'if' would be more precise > 3. SqlKeyword.DEFAULT clashes with SqlParserTokenType.DEFAULT > 4. SqlParserUtils.skipCommaOrRightParenthesis() can be generalized. It's > better to return the token it's met instead of obscure boolean (otherwise the > name should reflect the returned type) > 5. It makes sense to have a method to return the current token. The container > can be refactored from SqlLexerLookAheadToken, since lookahead token doesn't > need it's own class. > 6. SqlLexerTokenType.EOF does not mean 'end of FILE'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6942) Auto re-connect to other node in case of failure of current
[ https://issues.apache.org/jira/browse/IGNITE-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6942: Component/s: (was: sql) jdbc > Auto re-connect to other node in case of failure of current > --- > > Key: IGNITE-6942 > URL: https://issues.apache.org/jira/browse/IGNITE-6942 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Mikhail Cherkasov >Priority: Major > > it will be great to have a re-connect feature for thin driver, in case if > server failure it should choose another server node from a list of server > nods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-7373) Fix style guide violations and imprecise naming in SqlParser-related code
[ https://issues.apache.org/jira/browse/IGNITE-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reopened IGNITE-7373: - > Fix style guide violations and imprecise naming in SqlParser-related code > - > > Key: IGNITE-7373 > URL: https://issues.apache.org/jira/browse/IGNITE-7373 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Minor > > SQL parser implementation contains many abbreviation rule violations and > names that doesn't reflect the method intention: > 1. "token" instead of "tok" in variables > 2. SqlParserUtils.skipIfMatches throws an exception if the token doesn't > match, although the name doesn't reflect this. 'accept' or 'skip' without > 'if' would be more precise > 3. SqlKeyword.DEFAULT clashes with SqlParserTokenType.DEFAULT > 4. SqlParserUtils.skipCommaOrRightParenthesis() can be generalized. It's > better to return the token it's met instead of obscure boolean (otherwise the > name should reflect the returned type) > 5. It makes sense to have a method to return the current token. The container > can be refactored from SqlLexerLookAheadToken, since lookahead token doesn't > need it's own class. > 6. SqlLexerTokenType.EOF does not mean 'end of FILE'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6877) Improve behaviour for non-correlated subqueries
[ https://issues.apache.org/jira/browse/IGNITE-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768006#comment-16768006 ] Vladimir Ozerov edited comment on IGNITE-6877 at 2/14/19 8:49 AM: -- Closing due to long inactivity. Planner logic is to be redesigned soon, so tickets will be created as needed. was (Author: vozerov): Closing due to long inactivity. Planned logic is to be redesigned soon, so tickets will be created as needed. > Improve behaviour for non-correlated subqueries > --- > > Key: IGNITE-6877 > URL: https://issues.apache.org/jira/browse/IGNITE-6877 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Alin Andrei Corodescu >Priority: Minor > > Ignite behaves poorly in terms of performance when given queries which > contain IN or = operators followed by a non-correlated subquery. My guess is > that the query is actually run for each row of the table in order to test the > condition. > A possible solution is to store the results of the subquery in a temporary > table, and use it from there. > A workaround at the moment is to use joins instead of IN or = operators, but > this makes the query much more complicated. > Example: > SELECT name > FROM Employees > WHERE age IN (SELECT age FROM Customers) > The performance of this query is very slow for small amounts of data (about > 20 seconds for 4000 rows in each table last time I tried) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4757) SQL Query Metrics
[
https://issues.apache.org/jira/browse/IGNITE-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-4757.
---
> SQL Query Metrics
> -
>
> Key: IGNITE-4757
> URL: https://issues.apache.org/jira/browse/IGNITE-4757
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Denis Magda
>Priority: Major
>
> SQL queries monitoring part has to be improved. Suggest adding the metrics
> below.
> Per-query metrics. Total history size is defined by
> {{CacheConfiguration.getQueryDetailMetricsSize()}}:
> * Total query execution count.
> * Query execution time - min, max, avg. Provide a breakdown for map, per-join
> and reduce phases.
> * A number of bytes exchanged between nodes during query execution. Provide a
> per-join, unions, etc. breakdown.
> * A number rows returned - min, max, avg.
> * Collocated or non-collocated query.
> In addition, we need to introduce a way to filter out metrics for queries
> that complete faster than some predefined NNN time.
> Finally, research a possibility to put the metrics into the H2 execution
> plan. Create a separated ticket if this task in not completed under this
> ticket.
> Discussion on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Additional-SQL-metrics-td14945.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7373) Fix style guide violations and imprecise naming in SqlParser-related code
[ https://issues.apache.org/jira/browse/IGNITE-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7373. - Resolution: Fixed Not relevant. > Fix style guide violations and imprecise naming in SqlParser-related code > - > > Key: IGNITE-7373 > URL: https://issues.apache.org/jira/browse/IGNITE-7373 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Priority: Minor > > SQL parser implementation contains many abbreviation rule violations and > names that doesn't reflect the method intention: > 1. "token" instead of "tok" in variables > 2. SqlParserUtils.skipIfMatches throws an exception if the token doesn't > match, although the name doesn't reflect this. 'accept' or 'skip' without > 'if' would be more precise > 3. SqlKeyword.DEFAULT clashes with SqlParserTokenType.DEFAULT > 4. SqlParserUtils.skipCommaOrRightParenthesis() can be generalized. It's > better to return the token it's met instead of obscure boolean (otherwise the > name should reflect the returned type) > 5. It makes sense to have a method to return the current token. The container > can be refactored from SqlLexerLookAheadToken, since lookahead token doesn't > need it's own class. > 6. SqlLexerTokenType.EOF does not mean 'end of FILE'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6942) Auto re-connect to other node in case of failure of current
[ https://issues.apache.org/jira/browse/IGNITE-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-6942. - Resolution: Duplicate Already fixed. > Auto re-connect to other node in case of failure of current > --- > > Key: IGNITE-6942 > URL: https://issues.apache.org/jira/browse/IGNITE-6942 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Mikhail Cherkasov >Priority: Major > > it will be great to have a re-connect feature for thin driver, in case if > server failure it should choose another server node from a list of server > nods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11319) ignitevisorcmd can't handle incorrect !q parameter
Ilya Suntsov created IGNITE-11319:
-
Summary: ignitevisorcmd can't handle incorrect !q parameter
Key: IGNITE-11319
URL: https://issues.apache.org/jira/browse/IGNITE-11319
Project: Ignite
Issue Type: Task
Reporter: Ilya Suntsov
Please take a look at difference between "!q" and "\q" parameters:
{noformat}
visor> !q
[ERROR] Could not expand event
java.lang.IllegalArgumentException: !q: event not found
at jline.console.ConsoleReader.expandEvents(ConsoleReader.java:779)
at jline.console.ConsoleReader.finishBuffer(ConsoleReader.java:631)
at jline.console.ConsoleReader.accept(ConsoleReader.java:2019)
at jline.console.ConsoleReader.readLine(ConsoleReader.java:2666)
at jline.console.ConsoleReader.readLine(ConsoleReader.java:2269)
at
org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:214)
at
org.gridgain.visor.commands.VisorGridGainConsole$.delayedEndpoint$org$gridgain$visor$commands$VisorGridGainConsole$1(VisorGridGainConsole.scala:88)
at
org.gridgain.visor.commands.VisorGridGainConsole$delayedInit$body.apply(VisorGridGainConsole.scala:77)
at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:392)
at
scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
at scala.App$class.main(App.scala:76)
at
org.gridgain.visor.commands.VisorGridGainConsole$.main(VisorGridGainConsole.scala:77)
at
org.gridgain.visor.commands.VisorGridGainConsole.main(VisorGridGainConsole.scala)
visor> \q
[WARN ] Invalid command name: '\q'
[WARN ] Type 'help' to print commands list.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768049#comment-16768049 ] Ivan Bessonov commented on IGNITE-8571: --- DistributedBaselineConfiguration - AUTO_ADJUST_CONFIGURED_MESSAGE - %d for timeout - //set default value. - code style ChangeTopologyWatcher - "...lost partitions was detected" - typo ChangeTopologyWatcherTest - maybe GridFunc#nodeConsistentIds can be used, maybe not Everything else looks good. > Baseline auto-adjust feature > > > Key: IGNITE-8571 > URL: https://issues.apache.org/jira/browse/IGNITE-8571 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Now we have only one way to change BLAT - manually update it via console.sh > or API. > We need to add the possibility to change it automatically. Adjust to current > topology. > So, I propose 2 new distributed parameters which would be responsible to tune > this feature. > 1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto > adjusting baseline. > 2. autoAdjustTimeout - time which we would wait after the actual topology > change. But it would be reset if new discovery event happened. (node > join/exit). > We need to change API next way: > org.apache.ignite.IgniteCluster: > * isBaselineAutoAdjustEnabled() > * setBaselineAutoAdjustEnabled(boolean enabled); > * setBaselineAutoAdjustTimeout(long timeoutInMs); > Also, we need to ensure that all nodes would have the same > parameters(distributed parameters). > And we should be able to survive coordinator left during parameters changes. > When autoAdjustEnabled is true we should be block ability to manual baseline > change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reopened IGNITE-11216:
-
> Ignite.sh fails on Mac OS and Linux - Java 11
> -
>
> Key: IGNITE-11216
> URL: https://issues.apache.org/jira/browse/IGNITE-11216
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite.sh fails on Mac OS Mojave with the following JDK version:
> java version "11.0.2" 2019-01-15 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
> The same issue is reproduced on Linux and the workaround is discussed here:
> https://issues.apache.org/jira/browse/IGNITE-3
> The exception is as follows:
> {noformat}
> /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh:
> line 40: [: -eq: unary operator expected
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar)
> to field java.nio.Buffer.address
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.GridUnsafe$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795)
> at
> org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305)
> at
> org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99)
> Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class
> is unavailable.
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453)
> at
> org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112)
> ... 4 more
> Caused by: java.lang.IllegalAccessException: class
> org.apache.ignite.internal.util.GridUnsafe cannot access class
> jdk.internal.misc.SharedSecrets (in module java.base) because module
> java.base does not export jdk.internal.misc to unnamed module @4f83df68
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591)
> at java.base/java.lang.reflect.Method.invoke(Method.java:558)
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10720) Decrease time to save metadata during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768061#comment-16768061
]
Ignite TC Bot commented on IGNITE-10720:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3077132&buildTypeId=IgniteTests24Java8_RunAll]
> Decrease time to save metadata during checkpoint
>
>
> Key: IGNITE-10720
> URL: https://issues.apache.org/jira/browse/IGNITE-10720
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Looks like it's not neccessery save all metadata(like free list) under write
> checkpoint lock because sometimes it's too long.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11267) Print warning when keystore password arguments are used in control.sh (bat)
[ https://issues.apache.org/jira/browse/IGNITE-11267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-11267: -- Fix Version/s: 2.8 > Print warning when keystore password arguments are used in control.sh (bat) > --- > > Key: IGNITE-11267 > URL: https://issues.apache.org/jira/browse/IGNITE-11267 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Control utility gets keystore/truststore password either as command line > argument or as console input. Former way is insecure, and user should be > warned. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11217) After cluster kill and restart with new jvm option - one of node fail with failure type - Failed to read WAL record at position
[
https://issues.apache.org/jira/browse/IGNITE-11217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-11217:
--
Component/s: mvcc
> After cluster kill and restart with new jvm option - one of node fail with
> failure type - Failed to read WAL record at position
>
>
> Key: IGNITE-11217
> URL: https://issues.apache.org/jira/browse/IGNITE-11217
> Project: Ignite
> Issue Type: Bug
> Components: data structures, mvcc
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.8
>
>
> Test scenario:
> - Start two server load
> - execute operations (put/put-all/streamer/remove)
> - execute client that collect checksum
> - kill nodes
> - add JVM options to server - DIGNITE_WAL_LOG_TX_RECORDS=true,
> DIGNITE_RECOVERY_VERBOSE_LOGGING
> - start nodes
> - activate them
> Found that one node fail
> {code:java}
> [23:16:06,230][INFO][main][GridCacheProcessor] Finished restoring partition
> state for local groups [groupsProcessed=45, partitionsProcessed=764,
> time=557ms]
> [23:16:06,280][INFO][main][FileWriteAheadLogManager] Stopping WAL iteration
> due to an exception: Failed to read WAL record at position: 27700852 size:
> 67108864, ptr=FileWALPointer [idx=0, fileOff=27700852, len=0]
> [23:16:06,298][SEVERE][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connections
> class org.apache.ignite.IgniteCheckedException: Failed to read WAL record at
> position: 27700852 size: 67108864
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.handleRecordException(AbstractWalRecordsIterator.java:305)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.handleRecordException(FileWriteAheadLogManager.java:2691)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:269)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advance(AbstractWalRecordsIterator.java:158)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:127)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:53)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:41)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.tailPointer(GridCacheDatabaseSharedManager.java:1984)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1958)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
> at org.apache.ignite.Ignition.start(Ignition.java:348)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to read WAL
> record at position: 27700852 size: 67108864
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readWithCrc(RecordV1Serializer.java:395)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer.readRecord(RecordV2Serializer.java:236)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:254)
> ... 17 more
> Caused by: java.io.IOException: class
> org.apache.ignite.IgniteCheckedException: Unsupported protocol version: 34
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.readVersion(RecordDataV1Serializer.java:2010)
> at
> org.apache.ignite.internal.processors.cache.persistence.
[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&focusedCommentId=16768125#comment-16768125 ] Roman Shtykh commented on IGNITE-5983: -- [~amashenkov] Have you had a chance to look at the issue? > 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] [Commented] (IGNITE-11310) SQL: Remove special interaction between query parallelism and distributed joins
[ https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768135#comment-16768135 ] Vladimir Ozerov commented on IGNITE-11310: -- Fixed all failures. Most of them were caused by invalid changes to DML logic, I reverted them. New test run: https://ci.ignite.apache.org/viewQueued.html?itemId=3084726 > SQL: Remove special interaction between query parallelism and distributed > joins > --- > > Key: IGNITE-11310 > URL: https://issues.apache.org/jira/browse/IGNITE-11310 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently we enable so-called "local distributed joins" when query is > executed locally with enabled parallelism. This behavior is not needed and > needs to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10860) Exception on GridJobProcessor.stop()
[
https://issues.apache.org/jira/browse/IGNITE-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768137#comment-16768137
]
Ignite TC Bot commented on IGNITE-10860:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3083409]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlCoordinatorFailoverTest.testSqlReadInsideTxInProgressCoordinatorFails_ReadDelay
- 0,0% fails in last 0 master runs.
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlCoordinatorFailoverTest.testSqlReadInsideTxInProgressCoordinatorFails
- 0,0% fails in last 0 master runs.
{color:#d04437}MVCC PDS 1{color} [[tests
11|https://ci.ignite.apache.org/viewLog.html?buildId=3083471]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3 - 0,0%
fails in last 414 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3 -
0,0% fails in last 414 master runs.
{color:#d04437}Cache (Restarts) 2{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=3083422]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
- 0,5% fails in last 415 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutEightNodesTwoBackups - 0,5%
fails in last 415 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
- 0,5% fails in last 415 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,5%
fails in last 415 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
- 0,5% fails in last 415 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxSixNodesTwoBackups - 0,5%
fails in last 415 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxFourNodesOneBackups - 0,5%
fails in last 415 master runs.
{color:#d04437}SPI (URI Deploy){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3083392]]
* IgniteUriDeploymentTestSuite: GridHttpDeploymentSelfTest.testSameContantFiles
- 0,0% fails in last 319 master runs.
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3083386]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryNodeRestartSelfTest2.testRestarts - 0,0% fails in last 0 master
runs.
{color:#d04437}MVCC PDS 4{color} [[tests
22|https://ci.ignite.apache.org/viewLog.html?buildId=3083474]]
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testDeactivateFailover3
- 0,0% fails in last 419 master runs.
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testActivateFailover3
- 0,0% fails in last 419 master runs.
{color:#d04437}Cache (Full API){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3083420]]
* IgniteCacheFullApiSelfTestSuite:
GridCacheNearOnlyMultiNodeFullApiSelfTest.testTtlNoTx - 0,0% fails in last 579
master runs.
{color:#d04437}PDS 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3083442]]
* IgnitePdsTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3 - 0,0%
fails in last 418 master runs.
* IgnitePdsTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3 -
0,0% fails in last 418 master runs.
{color:#d04437}PDS 4{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3083445]]
* IgnitePdsTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testDeactivateFailover3
- 0,0% fails in last 422 master runs.
* IgnitePdsTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testActivateFailover3
- 0,0% fails in last 422 master runs.
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3083387]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3083476&buildTypeId=IgniteTests24Java8_RunAll]
> Exception on GridJobProcessor.stop()
>
>
> Key: IGNITE-10860
> URL: https://issues.apache.org/jira/browse/IGNITE-10860
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kurbanov
>Assignee: Anton Kurbanov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-9056 made calling clear() to throw UnsupportedOperationException from
> org.jsr166.Concurrent
[jira] [Updated] (IGNITE-11012) [ML] Add model type validation during parsing json file
[ https://issues.apache.org/jira/browse/IGNITE-11012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11012: -- Summary: [ML] Add model type validation during parsing json file (was: [ML] Add model type validation during parsing parquet file) > [ML] Add model type validation during parsing json file > --- > > Key: IGNITE-11012 > URL: https://issues.apache.org/jira/browse/IGNITE-11012 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > After resolving ignite path, check special field in parquet file to validate > apropriate model loading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11320) JDBC Thin: add support for individual reconnect in case of best effort affinity mode.
Alexander Lapin created IGNITE-11320: Summary: JDBC Thin: add support for individual reconnect in case of best effort affinity mode. Key: IGNITE-11320 URL: https://issues.apache.org/jira/browse/IGNITE-11320 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Fix For: 2.8 Currently in case of best effort affinity mode we either connect to all nodes specified by user or throw SQLException. Given logic needs to be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[
https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768175#comment-16768175
]
Ignite TC Bot commented on IGNITE-10693:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3077535&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: Random server restart tests became failed
> --
>
> Key: IGNITE-10693
> URL: https://issues.apache.org/jira/browse/IGNITE-10693
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails],
>
> [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails],
>
> [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails],
> all these tests became failed after IGNITE-9630 has been merged to master.
> Seems there is an issue in partition calculating mechanism on unstable
> topology. I suppose the algorithm uses partitions on nodes just become
> primary while the partitions are in moving state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7948) SQL: read only necessary fields into the row when possible
[
https://issues.apache.org/jira/browse/IGNITE-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768174#comment-16768174
]
Ignite TC Bot commented on IGNITE-7948:
---
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3077373&buildTypeId=IgniteTests24Java8_RunAll]
> SQL: read only necessary fields into the row when possible
> --
>
> Key: IGNITE-7948
> URL: https://issues.apache.org/jira/browse/IGNITE-7948
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> When H2 row is read, we always fill it with data eagerly through link
> materialization. Materialization is performed under page "read lock" what
> guarantees row-level consistency. This may lead to excessive memory pressure
> due to memory copying. For example, consider a class with 50 fields and a
> query which reads only 2 of them. 48 other fields will be copied without a
> reason. Lazy initialization is not an option because it will only defer
> memcpy, but not eliminate it.
> Instead we can try using H2. It passes {{TableFilter}} class to some of index
> access methods*. We can analyze this class and create the list of required
> fields. Then we can read these fields under read lock from offheap and put
> them to the row.
> In addition to saved memcpy this could give us more benefits:
> 1) No more need for field cache ({{GridH2KeyValueRowOnheap#valCache}})
> 2) No more need to read {{_VER}} column and possibly {{_KEY}} or {{_VAL}}
> But there are a number of drawbacks as well. E.g. it is impossible to read
> strings from offheap efficiently, so queries with VARCHAR will definitely
> suffer from this change.
> \* {{org.h2.index.Index#find(org.h2.table.TableFilter,
> org.h2.result.SearchRow, org.h2.result.SearchRow)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11322) [USABILITY] Extend Node FAILED message by add consistentId if it exist
ARomantsov created IGNITE-11322: --- Summary: [USABILITY] Extend Node FAILED message by add consistentId if it exist Key: IGNITE-11322 URL: https://issues.apache.org/jira/browse/IGNITE-11322 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: ARomantsov Fix For: 2.8 Now I having only this [GridDiscoveryManager] Node FAILED: TcpDiscoveryNode [id=f8cd73a1-8da5-4a07-b298-55634dd7c9f8, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1550141566893, loc=false, isClient=false] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11279) SQL: Remove H2's "prepared" from DML and local query plans
[
https://issues.apache.org/jira/browse/IGNITE-11279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-11279:
-
Ignite Flags: (was: Docs Required)
> SQL: Remove H2's "prepared" from DML and local query plans
> --
>
> Key: IGNITE-11279
> URL: https://issues.apache.org/jira/browse/IGNITE-11279
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently it is only used to get the list of participating tables. Instead,
> we should encapsulate this information into {{ParsingResultDml}}. Streamer
> methods should use our own parser as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
