[jira] [Updated] (IGNITE-13752) Schema evolution converters.

["Andrey Mashenkov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-13752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Mashenkov updated IGNITE-13752:
--------------------------------------
    Description: 
h3. Motivation.
The Live-schema concept supposes a tuple of old-version can be upgraded to a tuple of new-version automatically.

h3 Description.
Table SchemaManager tracks schema changes and keeps a history of changes.
Let's implements the mechanics to apply these historical changes to a Row to upgrade to the latest version.

Additionally, 
* investigate if some changes can be squashed, e.g. "drop column" and "add column" of the same name and create a ticket for this.
* Investigate if row upgrade can be "No-op" and just rises a schema version in a Row in-place without copying (e.g. a Row is tombstone 
or 'null' row was dropped and maybe we can rewrite the whole Row in-place) and create a ticket for possible optimizations.

  was:
With "live" schema it should be able to deserialize tuples of old-version to a new classes regarding schema change history.

Startpoint is to investigate if we could generate converter source->target schema version and them apply changes to data: e.g. column add, default value change.

 

Note: column removal should be made manually and class with absent field shouldn't triggers new schema version, but mapped to the latest known schema.

 

 


> Schema evolution converters.
> ----------------------------
>
>                 Key: IGNITE-13752
>                 URL: https://issues.apache.org/jira/browse/IGNITE-13752
>             Project: Ignite
>          Issue Type: Improvement
>          Components: sql
>            Reporter: Andrey Mashenkov
>            Priority: Major
>              Labels: iep-54, ignite-3
>
> h3. Motivation.
> The Live-schema concept supposes a tuple of old-version can be upgraded to a tuple of new-version automatically.
> h3 Description.
> Table SchemaManager tracks schema changes and keeps a history of changes.
> Let's implements the mechanics to apply these historical changes to a Row to upgrade to the latest version.
> Additionally, 
> * investigate if some changes can be squashed, e.g. "drop column" and "add column" of the same name and create a ticket for this.
> * Investigate if row upgrade can be "No-op" and just rises a schema version in a Row in-place without copying (e.g. a Row is tombstone 
> or 'null' row was dropped and maybe we can rewrite the whole Row in-place) and create a ticket for possible optimizations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)