[ https://issues.apache.org/jira/browse/IGNITE-14556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17322239#comment-17322239 ]
Andrey Mashenkov edited comment on IGNITE-14556 at 7/6/21, 9:53 AM: -------------------------------------------------------------------- Do we need an option to relax these checks for STRICT mode? and allow arbitrary fields in the Tuple, but ignore non-relevant while building a Row? Maybe this could be a default option? If so, we only need this validation for LIVE-schema to detect schema upgrades. was (Author: amashenkov): Do we need an option to relax these checks for STRICT mode? and allow to pass any fields within the Tuple, but ignore non-relevant while building a Row? Maybe this could be a default option? If so, we only need this validation for LIVE-schema to detect schema upgrade. > Live Schema. Add Tuple validation. > ---------------------------------- > > Key: IGNITE-14556 > URL: https://issues.apache.org/jira/browse/IGNITE-14556 > Project: Ignite > Issue Type: Improvement > Reporter: Andrey Mashenkov > Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 48h > Remaining Estimate: 48h > > h3. Motivation. > At a point of Table public method is called by a user, we need to validate > user input (for LIVE-schema purposes at least). > h3. Description. > We can add this logic to check if value fields match the current schema > version (no new fields). > * For LIVE-Schema. If Tuple has one or more additional columns, then we > should try to register a new schema first, then proceed with the user > operation. > * For STRICT-Schema. If Tuple has one or more additional columns, then we > should fail the user operation. > * For KeyValueView, we should validate key Tuple as well, and fail if there > are unknown columns. Because a key column span is immutable. The only > exception may be if a user creates a schemaless table, then a schema of the > 1-st version should be registered instantly. > Assumed, any column type mismatch or missed Non-Nullable columns will be > caught and processed by RowAssembler. > h4. Possible optimization. > It is possible to add the validation into a TupleBuilder and then just check > the Tuple instance class (should be a builder). > For any Tuple of unknown type or if a schema was changed concurrently > (TupleBuilder validated input against outdated schema version), then fallback > to default logic and re-validate input against the latest schema. > -- This message was sent by Atlassian Jira (v8.3.4#803005)