[
https://issues.apache.org/jira/browse/IGNITE-20907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-20907:
---------------------------------------
Description:
Currently, only a small number of <from, to> pairs are allowed when changing a
column type with ALTER TABLE ... ALTER COLUMN... SET DATA TYPE, see
[IEP-108|https://cwiki.apache.org/confluence/display/IGNITE/IEP-108+Change+column+type#IEP108Changecolumntype-Proposal.].
When it comes to columns that are not indexed, we can increase the set of
allowable type changes: we can allow any change for which we can guarantee that
any value that is a member of the original type is represented losslessly in
the new type (in other words, any value converted from the original type to the
new type and then converted back will produce the same value as before the
double conversion). Each tuple is accompanied with table version in the MV
storage, so we can always determine the corresponding schema version V and
convert the value in memory when it's read using any table version V' (where
V'>=V). We already have a mechanism of upgrading adapters on read, the
mecnanism can be leveraged for type conversion.
As for indexed columns, the simpliest solution for now is to leave the current
(strict) rules for changing their types as indices seem to require that the
binary representation of all values in the original type remains the same to
avoid index rebuild. This can be addressed later.
The set of allowable type changes (probably incomplete, this has to be
carefully checked) follows:
* INT(N) -> INT(M), where N<M
* FLOAT -> DOUBLE
* INT(N) -> FLOAT/DOUBLE (where N guarantees backward convertibility for each
INT(N) value; for instance, for FLOAT N=8/16)
* INT(N) <-> NUMBER(P, S), where N, P, S guarantee lossless conversion
* INT(N) <-> DECIMAL(P, S), where N, P, S guarantee lossless conversion
* NUMBER(P1, S1) <-> DECIMAL(P1, S1), where parameters guarantee lossless
conversion
* NUMBER(P1, S1) <-> NUMBER(P1, S1), where parameters guarantee lossless
conversion
* DECIMAL(P1, S1) <-> DECIMAL(P1, S1), where parameters guarantee lossless
conversion
* STRING(L1) -> STRING(L2), where L1<L2
* <any mentioned type but floating point> <-> STRING(L), where parameters
guarantee lossless conversion
was:
Currently, only a small number of <from, to> pairs are allowed when changing a
column type with ALTER TABLE ... ALTER COLUMN... SET DATA TYPE, see
[IEP-108|https://cwiki.apache.org/confluence/display/IGNITE/IEP-108+Change+column+type#IEP108Changecolumntype-Proposal.].
When it comes to columns that are not indexed, we can increase the set of
allowable type changes: we can allow any change for which we can guarantee that
any value that is a member of the original type is represented losslessly in
the new type (in other words, any value converted from the original type to the
new type and then converted back will produce the same value as before the
double conversion). Each tuple is accompanied with table version in the MV
storage, so we can always determine the corresponding schema version V and
convert the value in memory when it's read using any table version V' (where
V'>=V). We already have a mechanism of upgrading adapters on read, the
mecnanism can be leveraged for type conversion.
As for indexed columns, the simpliest solution for now is to leave the current
(strict) rules for changing their types as indices seem to require that the
binary representation of all values in the original type remains the same to
avoid index rebuild. This can be addressed later.
> Support column type changes that do not require existing data conversion
> ------------------------------------------------------------------------
>
> Key: IGNITE-20907
> URL: https://issues.apache.org/jira/browse/IGNITE-20907
> Project: Ignite
> Issue Type: Improvement
> Components: sql
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> Currently, only a small number of <from, to> pairs are allowed when changing
> a column type with ALTER TABLE ... ALTER COLUMN... SET DATA TYPE, see
> [IEP-108|https://cwiki.apache.org/confluence/display/IGNITE/IEP-108+Change+column+type#IEP108Changecolumntype-Proposal.].
> When it comes to columns that are not indexed, we can increase the set of
> allowable type changes: we can allow any change for which we can guarantee
> that any value that is a member of the original type is represented
> losslessly in the new type (in other words, any value converted from the
> original type to the new type and then converted back will produce the same
> value as before the double conversion). Each tuple is accompanied with table
> version in the MV storage, so we can always determine the corresponding
> schema version V and convert the value in memory when it's read using any
> table version V' (where V'>=V). We already have a mechanism of upgrading
> adapters on read, the mecnanism can be leveraged for type conversion.
> As for indexed columns, the simpliest solution for now is to leave the
> current (strict) rules for changing their types as indices seem to require
> that the binary representation of all values in the original type remains the
> same to avoid index rebuild. This can be addressed later.
> The set of allowable type changes (probably incomplete, this has to be
> carefully checked) follows:
> * INT(N) -> INT(M), where N<M
> * FLOAT -> DOUBLE
> * INT(N) -> FLOAT/DOUBLE (where N guarantees backward convertibility for
> each INT(N) value; for instance, for FLOAT N=8/16)
> * INT(N) <-> NUMBER(P, S), where N, P, S guarantee lossless conversion
> * INT(N) <-> DECIMAL(P, S), where N, P, S guarantee lossless conversion
> * NUMBER(P1, S1) <-> DECIMAL(P1, S1), where parameters guarantee lossless
> conversion
> * NUMBER(P1, S1) <-> NUMBER(P1, S1), where parameters guarantee lossless
> conversion
> * DECIMAL(P1, S1) <-> DECIMAL(P1, S1), where parameters guarantee lossless
> conversion
> * STRING(L1) -> STRING(L2), where L1<L2
> * <any mentioned type but floating point> <-> STRING(L), where parameters
> guarantee lossless conversion
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
