[
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:23 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)}}, {{QueryEntityTypeDescriptor#keyProps}} not preserve fields
order of the MyKey class.
- 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 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 (?, ?, ?)}}
> 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)
