[
https://issues.apache.org/jira/browse/CASSANDRA-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296478#comment-15296478
]
Alex Petrov commented on CASSANDRA-7190:
----------------------------------------
I've changed a syntax a bit, to be consistent with the rest of grammar: {{ALTER
TABLE %s DROP todrop USING TIMESTAMP 1;}} as {{WITH}} keyword is already used
in this statement for something different (table attributes). It's also
possible to specify a different timestamp for each dropped column.
The only pitfalls I currently see is that:
* drop timestamp is recorded in microseconds, although then rounded to
millisecond resolution.
* when schema is updated, during announcement of migration,
{{switchMemtable}} is called and the table is flushed to SSTable with new
metadata, which means that all the columns will be lost during the write
iteration. That might be unwanted behaviour, as if that'd be a feature that
could be used as [~slebresne] described (incrementally getting rid of data), on
each memtable flush all columns, disregarding timestamp, from that memtable,
will be lost. Writing dropped column data as well is possible, but in majority
of cases will be an unnecessary effort.
Do we want keep it that way?
> Add schema to snapshot manifest
> -------------------------------
>
> Key: CASSANDRA-7190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7190
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Alex Petrov
> Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
>
> followup from CASSANDRA-6326
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
