[
https://issues.apache.org/jira/browse/IGNITE-14556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14556:
--------------------------------------
Description:
h3. 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. 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. 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.
was:
Motivation.
At a point of Table public method call by a user, we need to validate user
input.
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.
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.
> 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
>
> h3. 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. 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. 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)
