[ https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483637#comment-17483637 ]
Taras Ledkov edited comment on IGNITE-16098 at 1/28/22, 8:22 AM: ----------------------------------------------------------------- Validation schema of the key object contains backward compatibility broken changes because: - when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class, MyValue.class)}}, because {{QueryEntityTypeDescriptor#keyProps}} not preserve order. - SQL INSERT not preserve order of the keyField on key object building; - SQL INSERT now creates different schemas for {{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}} and {{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}} was (Author: tledkov-gridgain): Validation schema of the key object contains backward compatibility broken changes: - when QueryEntity is created from real classes: {{new QueryEntity(MyKey.class, MyValue.class)}}, because {{QueryEntityTypeDescriptor#keyProps}} not preserve order. - SQL INSERT not preserve order of the keyField on key object building; - SQL INSERT now creates different schemas for {{INSERT INTO T0 (ID0, VAL) VALUES (?, ?, ?)}} and {{INSERT INTO T0 (ID0, ID1, VAL) VALUES (?, ?, ?)}} > 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 > > 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.1#820001)