[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
----------------------------------
Description:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
was:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
> Key type and schema must be validated on a data insertion
> ---------------------------------------------------------
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.11
> Reporter: Taras Ledkov
> Assignee: Taras Ledkov
> Priority: Major
> Fix For: 2.13
>
>
> There are two cases that break the consistency between indexes and data and
> can cause the index tree to break.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#valueType}} the entity is not
> indexed (not applied fr the table).
> But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
> fields of inserted entry are validated.
> Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
> different types. Such insertion produce critical error.
> But this property is set up on the first insertion on the node locally.
> So, the steps to fail:
> 1. Put key with type "Key0" on the one node - OK;
> 2. Put key with type "Key1" on the other node - OK;
> 3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
> build index);
> *Suggestion fix:*
> 1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the second case);
> 2. *Before* table creation register {{BinaryMetadata}} for specified key type;
> 3. If the type corresponding for KEY is already registered and schemas differ
> - fail the table creation;
> 3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
> cluster-wide propagation and store at the persistence configuration;
> 4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the first case)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
