You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Roman Puchkovskiy (Jira)" <ji...@apache.org> on 2026/03/23 13:49:00 UTC
[jira] [Updated] (IGNITE-28335) Make column drop a compatible schema change
[ https://issues.apache.org/jira/browse/IGNITE-28335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roman Puchkovskiy updated IGNITE-28335:
---------------------------------------
Description:
Currently, dropping a column is considered an incompatible schema change because there is a possibility to lose information in the following scenario:
# User writes a tuple in schema V1, sending column C=X explicitly in transaction tx1
# DROP COLUMN X is executed
# tx1 gets committed
# If we allow it to be committed, then:
## The user would know that they had written C=X, so the user would expect the schema to still be the one in which they would be able to read C
## But in reality, the tuple would be associated with schema V2 lacking column C, so it would be possible to read C from the tuple
After reconsideration, it seems that the problematic case is too edgy to make everyone to pay the price of rollbacks when dropping a column.
We need to do the following:
# Make column drop a compatible schema change
# Document the problematic edge case for the users to be aware
# Modify the IEP?
The IEP is here: https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes
> Make column drop a compatible schema change
> -------------------------------------------
>
> Key: IGNITE-28335
> URL: https://issues.apache.org/jira/browse/IGNITE-28335
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> Currently, dropping a column is considered an incompatible schema change because there is a possibility to lose information in the following scenario:
> # User writes a tuple in schema V1, sending column C=X explicitly in transaction tx1
> # DROP COLUMN X is executed
> # tx1 gets committed
> # If we allow it to be committed, then:
> ## The user would know that they had written C=X, so the user would expect the schema to still be the one in which they would be able to read C
> ## But in reality, the tuple would be associated with schema V2 lacking column C, so it would be possible to read C from the tuple
> After reconsideration, it seems that the problematic case is too edgy to make everyone to pay the price of rollbacks when dropping a column.
> We need to do the following:
> # Make column drop a compatible schema change
> # Document the problematic edge case for the users to be aware
> # Modify the IEP?
> The IEP is here: https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)