[
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)
