[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-16098:
-------------------------------------
Assignee: Taras Ledkov (was: Taras Ledkov)
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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, PRIMARY KEY (ID0, ID1)) 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)
> 5. Introduce distributed property to disable these validation for backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
