[jira] [Commented] (CASSANDRA-14846) Drop/Add Column Pre-existing Data Inconsistency

["Benedict (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-14846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16886770#comment-16886770 ] 

Benedict commented on CASSANDRA-14846:
--------------------------------------

So, the real bug here is that we don't do this reliably.  There are race conditions with incompatible types in multiple locations, including compaction, internode messaging and client query execution.

By fixing these inconsistencies, we should be able to remove the need for the type of any new column to be compatible with the type of any previous incarnation of the column.

> Drop/Add Column Pre-existing Data Inconsistency
> -----------------------------------------------
>
>                 Key: CASSANDRA-14846
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14846
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL/Semantics, Local/SSTable
>            Reporter: Benedict
>            Priority: Normal
>
> If we drop a column, any data that is compacted before we add a column with the same name (and compatible type) will be lost, but any data that was not compacted will continue to be returned.  This seems problematic - surely we should consider all data prior to a Drop to be lost?  Re-adding a column of the same name should reset the column’s contents?
> This would also permit us to not worry about the types being consistent in the case of a dropped column (only alter column need worry about this)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org