[
https://issues.apache.org/jira/browse/CASSANDRA-18961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779574#comment-17779574
]
Jacek Lewandowski commented on CASSANDRA-18961:
-----------------------------------------------
The issue can be demonstrated with this CQL:
{code:sql}
CREATE KEYSPACE ks WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor': 1};
CREATE TABLE ks.tab (id INT PRIMARY KEY, a INT, b INT, c INT);
INSERT INTO ks.tab (id, a, b, c) VALUES (1, 1, 1, 1);
ALTER TABLE ks.tab DROP (c);
INSERT INTO ks.tab (id, a, b) VALUES (2, 2, 2);
ALTER TABLE ks.tab ADD c INT;
INSERT INTO ks.tab (id, a, b, c) VALUES (3, 3, 3, 3);
SELECT * FROM ks.tab;
{code}
restart the node, then
{code:sql}
SELECT * FROM ks.tab;
{code}
> Record commit timestamp - fix data loss when dropping and recreating a column
> -----------------------------------------------------------------------------
>
> Key: CASSANDRA-18961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18961
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
>
> Drop column transformation is replayed with the current timestamp so the
> column appears to be dropped when the node starts regardless of its real drop
> time.
> As a solution to this problem I propose recording the timestamp of the
> transformation, guaranteeing that it is always greater than a timestamp of
> any previously committed transformation. Such timestamp is passed to the
> execute method of the transformation so that the transformation code can make
> use of it, increasing its "purity".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
