[
https://issues.apache.org/jira/browse/CASSANDRA-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308031#comment-15308031
]
Aleksey Yeschenko commented on CASSANDRA-7190:
----------------------------------------------
Close, but not enough, yet.
1. You do still need the column to be present to drop it, even with a
timestamp, in the patch, which makes it impossible to record a drop of a
currently non-existing column and thus doesn't address CASSANDRA-11416 problem.
One way to address it would be to include the already dropped column in the
list of columns for the table schema, and then reply {{ALTER TABLE DROP}} on
top of it. Will need to handle drop and re-add cases, too, so if a column was
dropped and exists now, DROP will need to be followed up with {{ALTER TABLE
ADD}} for the re-add.
2. The output should be a single CQL schema file that can be fed into cqlsh and
produce an equivalent schema on a new cluster. As such, need to consolidate
currently separate tables/indexes/dropped columns/user types, and take care of
proper sequencing, too.
> 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.0.x, 3.x
>
>
> followup from CASSANDRA-6326
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
