[jira] [Resolved] (IGNITE-13436) Custom BinaryIdMapper is not working
[
https://issues.apache.org/jira/browse/IGNITE-13436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeniy Rudenko resolved IGNITE-13436.
--
Resolution: Duplicate
Duplicate of https://issues.apache.org/jira/browse/IGNITE-13415
> Custom BinaryIdMapper is not working
>
>
> Key: IGNITE-13436
> URL: https://issues.apache.org/jira/browse/IGNITE-13436
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Evgeniy Rudenko
>Priority: Major
>
> {color:#1d1c1d}Custom BinaryIdMapper will not be used for
> org.apache.ignite.internal.binary.BinaryContext#createField unless cache.put
> operation was called before it. This happens because typeId2Mapper is not
> filled otherwise. {color}
> {color:#1d1c1d}[http://apache-ignite-users.70518.x6.nabble.com/Unable-to-read-fields-value-from-BinaryObject-td33925.html]{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13436) Custom BinaryIdMapper is not working
Evgeniy Rudenko created IGNITE-13436:
Summary: Custom BinaryIdMapper is not working
Key: IGNITE-13436
URL: https://issues.apache.org/jira/browse/IGNITE-13436
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Evgeniy Rudenko
{color:#1d1c1d}Custom BinaryIdMapper will not be used for
org.apache.ignite.internal.binary.BinaryContext#createField unless cache.put
operation was called before it. This happens because typeId2Mapper is not
filled otherwise. {color}
{color:#1d1c1d}[http://apache-ignite-users.70518.x6.nabble.com/Unable-to-read-fields-value-from-BinaryObject-td33925.html]{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13364) Improve index inline defaults
[ https://issues.apache.org/jira/browse/IGNITE-13364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13364: - Fix Version/s: 2.10 > Improve index inline defaults > -- > > Key: IGNITE-13364 > URL: https://issues.apache.org/jira/browse/IGNITE-13364 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to improve how inline size is calculated by default for > variable-length types. > Currently if a varlength type is encountered inline size just defaults to 10, > which is almost always not enough. > A more sensible behavior would be the following: > 1. Add a fixed default to the inline size calculation for every > variable-length type. For example, if the default inlined size for a string > is 10 then an index like (INT, VARCHAR, VARCHAR, INT) should have inline size > default as 5 + 10 + 10 + 5 = 30 (5 for each int, 10 for each string). > 2. Add special support for VARCHAR_FIXED - if a VARCHAR has known length then > that length is used for inline size calculation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13364) Improve index inline defaults
[ https://issues.apache.org/jira/browse/IGNITE-13364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13364: - Component/s: sql > Improve index inline defaults > -- > > Key: IGNITE-13364 > URL: https://issues.apache.org/jira/browse/IGNITE-13364 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > > We need to improve how inline size is calculated by default for > variable-length types. > Currently if a varlength type is encountered inline size just defaults to 10, > which is almost always not enough. > A more sensible behavior would be the following: > 1. Add a fixed default to the inline size calculation for every > variable-length type. For example, if the default inlined size for a string > is 10 then an index like (INT, VARCHAR, VARCHAR, INT) should have inline size > default as 5 + 10 + 10 + 5 = 30 (5 for each int, 10 for each string). > 2. Add special support for VARCHAR_FIXED - if a VARCHAR has known length then > that length is used for inline size calculation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13364) Improve index inline defaults
Evgeniy Rudenko created IGNITE-13364: Summary: Improve index inline defaults Key: IGNITE-13364 URL: https://issues.apache.org/jira/browse/IGNITE-13364 Project: Ignite Issue Type: Improvement Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko We need to improve how inline size is calculated by default for variable-length types. Currently if a varlength type is encountered inline size just defaults to 10, which is almost always not enough. A more sensible behavior would be the following: 1. Add a fixed default to the inline size calculation for every variable-length type. For example, if the default inlined size for a string is 10 then an index like (INT, VARCHAR, VARCHAR, INT) should have inline size default as 5 + 10 + 10 + 5 = 30 (5 for each int, 10 for each string). 2. Add special support for VARCHAR_FIXED - if a VARCHAR has known length then that length is used for inline size calculation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13259) "default" cache usage should be removed from REST API
[ https://issues.apache.org/jira/browse/IGNITE-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13259: - Release Note: Removed "default" cache from Cache and Query REST APIs. User will receive "Failed to find mandatory parameter in request: cacheName" if cache name is not provided. > "default" cache usage should be removed from REST API > - > > Key: IGNITE-13259 > URL: https://issues.apache.org/jira/browse/IGNITE-13259 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Right now lots of REST APIs will try to use "default" cache if cacheName is > not provided. This is pointless because such cache doesn't exist by default. > It will be better to change current behavior and return correct error instead > of "Failed to find cache for given cache name: default". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13259) "default" cache usage should be removed from REST API
Evgeniy Rudenko created IGNITE-13259: Summary: "default" cache usage should be removed from REST API Key: IGNITE-13259 URL: https://issues.apache.org/jira/browse/IGNITE-13259 Project: Ignite Issue Type: Improvement Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko Right now lots of REST APIs will try to use "default" cache if cacheName is not provided. This is pointless because such cache doesn't exist by default. It will be better to change current behavior and return correct error instead of "Failed to find cache for given cache name: default". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153613#comment-17153613 ] Evgeniy Rudenko commented on IGNITE-13216: -- [~ilyak] Thank you. > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > If "name" parameter is set it should be used instead of actual field name. > Currently if 2 @QuerySqlField fields have same names we will receive error, > even if they have different "name" properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13216: - Description: (was: If "name" parameter is set it should be used instead of actual field name. Currently if 2 @QuerySqlField fields have same names we will receive error, even if they have different "name" properties.) > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) SQL: Fix incorrect check for conflict of field names in key and value.
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeniy Rudenko updated IGNITE-12561:
-
Release Note: Added validation of the uniqueness of field's name annotated
with @QuerySqlEntity. Previously cache could be started without errors, but the
key's field would not be queryable:
> SQL: Fix incorrect check for conflict of field names in key and value.
> --
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
Evgeniy Rudenko created IGNITE-13216: Summary: QuerySqlField annotation's "name" property is not used during validation of known fields names Key: IGNITE-13216 URL: https://issues.apache.org/jira/browse/IGNITE-13216 Project: Ignite Issue Type: Bug Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko Fix For: 2.9 If "name" parameter is set it should be used instead of actual field name. Currently if 2 @QuerySqlField fields have same names we will receive error, even if they have different "name" properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12973) Support inlining of BigDecimal
[ https://issues.apache.org/jira/browse/IGNITE-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko reassigned IGNITE-12973: Assignee: (was: Evgeniy Rudenko) > Support inlining of BigDecimal > -- > > Key: IGNITE-12973 > URL: https://issues.apache.org/jira/browse/IGNITE-12973 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > > SQL currently doesn't support inlining for indexes over BigDecimal although > there seem to be no strong reason for that. It is quite often that decimal > types are used in FinTech apps and inability to efficiently use them in SQL > conditions can make migration to SQL a lot harder. > Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12973) Support inlining of BigDecimal
[ https://issues.apache.org/jira/browse/IGNITE-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101544#comment-17101544 ] Evgeniy Rudenko commented on IGNITE-12973: -- Couldn't implement update because of the slow work of H2's ValueDecimal. > Support inlining of BigDecimal > -- > > Key: IGNITE-12973 > URL: https://issues.apache.org/jira/browse/IGNITE-12973 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > > SQL currently doesn't support inlining for indexes over BigDecimal although > there seem to be no strong reason for that. It is quite often that decimal > types are used in FinTech apps and inability to efficiently use them in SQL > conditions can make migration to SQL a lot harder. > Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12973) Support inlining of BigDecimal
[ https://issues.apache.org/jira/browse/IGNITE-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-12973: - Release Note: BigDecimal values will be used in the index now. > Support inlining of BigDecimal > -- > > Key: IGNITE-12973 > URL: https://issues.apache.org/jira/browse/IGNITE-12973 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > > SQL currently doesn't support inlining for indexes over BigDecimal although > there seem to be no strong reason for that. It is quite often that decimal > types are used in FinTech apps and inability to efficiently use them in SQL > conditions can make migration to SQL a lot harder. > Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12973) Support inlining of BigDecimal
[ https://issues.apache.org/jira/browse/IGNITE-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-12973: - Fix Version/s: 2.9 > Support inlining of BigDecimal > -- > > Key: IGNITE-12973 > URL: https://issues.apache.org/jira/browse/IGNITE-12973 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > > SQL currently doesn't support inlining for indexes over BigDecimal although > there seem to be no strong reason for that. It is quite often that decimal > types are used in FinTech apps and inability to efficiently use them in SQL > conditions can make migration to SQL a lot harder. > Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12973) Support inlining of BigDecimal
Evgeniy Rudenko created IGNITE-12973: Summary: Support inlining of BigDecimal Key: IGNITE-12973 URL: https://issues.apache.org/jira/browse/IGNITE-12973 Project: Ignite Issue Type: Improvement Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko SQL currently doesn't support inlining for indexes over BigDecimal although there seem to be no strong reason for that. It is quite often that decimal types are used in FinTech apps and inability to efficiently use them in SQL conditions can make migration to SQL a lot harder. Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12672) Query annotations are not working if statement keywords are in lower case
[ https://issues.apache.org/jira/browse/IGNITE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037092#comment-17037092 ] Evgeniy Rudenko commented on IGNITE-12672: -- [~ilyak] fixed that > Query annotations are not working if statement keywords are in lower case > - > > Key: IGNITE-12672 > URL: https://issues.apache.org/jira/browse/IGNITE-12672 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > SQL queries defined using > org.apache.ignite.springdata.repository.config.Query annotations are not > working if key words (such as UPDATE or DELETE) are written using lower case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12672) Query annotations are not working if statement keywords are in lower case
[ https://issues.apache.org/jira/browse/IGNITE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-12672: - Reviewer: Ilya Kasnacheev > Query annotations are not working if statement keywords are in lower case > - > > Key: IGNITE-12672 > URL: https://issues.apache.org/jira/browse/IGNITE-12672 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > SQL queries defined using > org.apache.ignite.springdata.repository.config.Query annotations are not > working if key words (such as UPDATE or DELETE) are written using lower case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12672) Query annotations are not working if statement keywords are in lower case
Evgeniy Rudenko created IGNITE-12672: Summary: Query annotations are not working if statement keywords are in lower case Key: IGNITE-12672 URL: https://issues.apache.org/jira/browse/IGNITE-12672 Project: Ignite Issue Type: Bug Components: sql Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko Fix For: 2.9 SQL queries defined using org.apache.ignite.springdata.repository.config.Query annotations are not working if key words (such as UPDATE or DELETE) are written using lower case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12561) Add a check for conflict of field names in key and value
Evgeniy Rudenko created IGNITE-12561:
Summary: Add a check for conflict of field names in key and value
Key: IGNITE-12561
URL: https://issues.apache.org/jira/browse/IGNITE-12561
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Evgeniy Rudenko
Assignee: Evgeniy Rudenko
If key and value types of an SQL-enabled cache have the same fields annotated
with `@QuerySqlEntity` the cache will start without errors but the key's field
will not be queryable:
{color:#172b4d}{{{color:#505f79}// here, you can't query Key.a via
SQL{color}{color:#0052cc}class{color} {color:#6554c0}Key{color} {
@QuerySqlField {color:#0052cc}int{color} a; @QuerySqlField
{color:#0052cc}int{color} b; }{color:#0052cc}class{color}
{color:#6554c0}Value{color} { @QuerySqlField {color:#0052cc}int{color} a;
@QuerySqlField {color:#0052cc}int{color} c; }}}{color}
To workaround that, one needs to specify a different name for one of the `a`
fields:
{color:#172b4d}{{{color:#0052cc}class{color} {color:#6554c0}Key{color} {
@QuerySqlField(name = {color:#36b37e}"key_a"{color}) {color:#0052cc}int{color}
a; @QuerySqlField {color:#0052cc}int{color} b; }{color:#0052cc}class{color}
{color:#6554c0}Value{color} { @QuerySqlField {color:#0052cc}int{color} a;
@QuerySqlField {color:#0052cc}int{color} c; }}}{color}
The first configuration is obviously incorrect - one can't use the `Key.a` in
SQL but annotates it as queryable. We need to issue an error or at least a
warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-11917) Row count [select count(*) from table] not matching with the actual row count present in the table
[
https://issues.apache.org/jira/browse/IGNITE-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeniy Rudenko resolved IGNITE-11917.
--
Resolution: Duplicate
Assignee: (was: Evgeniy Rudenko)
Fix Version/s: 2.8
Dup of IGNITE-11438, will be fixed in Ignite 2.8
> Row count [select count(*) from table] not matching with the actual row count
> present in the table
> ---
>
> Key: IGNITE-11917
> URL: https://issues.apache.org/jira/browse/IGNITE-11917
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: shivakumar
>Priority: Major
> Fix For: 2.8
>
>
> To reproduce, create a sample table using JDBC endpoint:
> {code}
> CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY
> KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person,
> KEY_TYPE=personKey,VALUE_TYPE=person";
> {code}
> and configure cache expiry policy as below
> {code}
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>
> factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> with above cache configuration records will start expiring at the end of 10
> minute, batch insert around 1 records to the table and after 10 minute
> records will start expiring but after some time check the records count
> [select count(*) from person] most of the time it will show some non zero
> number but if rows are selected instead of count to see the actual data with
> [select * from person] there will be zero rows.
> why count is not becoming zero even though there is no data (rows) in the
> table ?
>
> {code}
> 0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from person;
> ++
> |COUNT(*)|
> ++
> |70|
> ++
> 1 row selected (0.004 seconds)
> 0: jdbc:ignite:thin://10.*.*.*:10800> select * from person;
>
> +--+--++++-
> |ID|BIRTHTIME|NAME|
> +--+--++++-
>
> +--+--++++-
> No rows selected (0.015 seconds)
> 0: jdbc:ignite:thin://10.*.*.*:10800>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (IGNITE-11917) Row count [select count(*) from table] not matching with the actual row count present in the table
[ https://issues.apache.org/jira/browse/IGNITE-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko reassigned IGNITE-11917: Assignee: Evgeniy Rudenko > Row count [select count(*) from table] not matching with the actual row count > present in the table > --- > > Key: IGNITE-11917 > URL: https://issues.apache.org/jira/browse/IGNITE-11917 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: shivakumar >Assignee: Evgeniy Rudenko >Priority: Major > > To reproduce, create a sample table using JDBC endpoint: > CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY > KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person, > KEY_TYPE=personKey,VALUE_TYPE=person"; > > and configure cache expiry policy as below > > > class="org.apache.ignite.configuration.CacheConfiguration"> > > > > > > factory-method="factoryOf"> > > > > > > > > > > > > with above cache configuration records will start expiring at the end of 10 > minute, batch insert around 1 records to the table and after 10 minute > records will start expiring but after some time check the records count > [select count(*) from person] most of the time it will show some non zero > number but if rows are selected instead of count to see the actual data with > [select * from person] there will be zero rows. > why count is not becoming zero even though there are now data (rows) in the > table ? > > > 0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from person; > ++ > |COUNT(*)| > ++ > |70| > ++ > 1 row selected (0.004 seconds) > 0: jdbc:ignite:thin://10.*.*.*:10800> select * from person; > > +-+---++++- > |ID|BIRTHTIME|NAME| > +-+---++++- > > +-+---++++- > No rows selected (0.015 seconds) > 0: jdbc:ignite:thin://10.*.*.*:10800> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11832) Creating cache with EvictionPolicy and without onHeap cache kills the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko resolved IGNITE-11832. -- Resolution: Cannot Reproduce Can't reproduce in latest release > Creating cache with EvictionPolicy and without onHeap cache kills the cluster > - > > Key: IGNITE-11832 > URL: https://issues.apache.org/jira/browse/IGNITE-11832 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Assignee: Evgeniy Rudenko >Priority: Critical > Labels: usability > > After this, the cluster can be restored only by deleting the folder with the > problem cache. We should add some kind of validation to avoid these > situations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11832) Creating cache with EvictionPolicy and without onHeap cache kills the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko reassigned IGNITE-11832: Assignee: Evgeniy Rudenko > Creating cache with EvictionPolicy and without onHeap cache kills the cluster > - > > Key: IGNITE-11832 > URL: https://issues.apache.org/jira/browse/IGNITE-11832 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Assignee: Evgeniy Rudenko >Priority: Critical > Labels: usability > > After this, the cluster can be restored only by deleting the folder with the > problem cache. We should add some kind of validation to avoid these > situations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
