Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 14 Nov 2012 14:26:12 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <1118809011.113922.1352903172174.JavaMail.jiratomcat@arcas>
In-Reply-To: <1926918208.81645.1352309471441.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (CASSANDRA-4929) Deal with broken ALTER DROP
 support in CQL3
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sylvain Lebresne commented on CASSANDRA-4929:
---------------------------------------------

bq. If we think we could do 3919 for 1.2.1 or .2 then my preferred option would be "leave DROP out entirely for now."

As said above, I'm fine with that. Worst case scenario, if #3919 proves trickier than we sought and/or if we find some compelling use case for a drop that only drops the metadata, we can add that later. For now, attaching patch to remove the support (the patch simply makes the syntax invalid, I figured there is no reason to remove code internally that we'll need for CASSANDRA-3919).

bq. I think there's a valid use case in wanting to drop metadata for individual column definitions

Which would be?
                
> Deal with broken ALTER DROP support in CQL3
> -------------------------------------------
>
>                 Key: CASSANDRA-4929
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4929
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.2.0 beta 1
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2.0 rc1
>
>         Attachments: 4929.txt
>
>
> Currently, {{ALTER DROP}} only remove the metadata for the column, making it unavailable, but don't reclaim the data. This is unintuive and CASSANDRA-3919 is opened to fix it. However, that later issue won't make it for 1.2, and I think we should be very careful into shipping 1.2 with the current behavior because 1) it's unintuitive and 2) as unintuitive as it is, we don't want people to start relying on that behavior. So I thing we should do one of:
> * remove support for {{ALTER DROP}} until CASSANDRA-3919 reintroduce it. After all, there is no real performance impact in keeping a colum that you don't use and if you really really want to get rid of the metadata, you still have the workaround of trashing the schema and recreating it without that column (obviously not user friendly, but at least it's vaguely possible).
> * add a specific syntax for the current behavior of {{ALTER DROP}}, one that clearly imply that the data is not deleted, if we consider that this behavior can be sometimes useful (that is, even after CASSANDRA-3919 is resolved). One such syntax could one of (not sure which one I prefer):
> {noformat}
> ALTER TABLE foo DROP my_column SCHEMA ONLY
> ALTER TABLE foo DROP my_column KEEP DATA
> {noformat}
> I have a slight preference for solution 2, but honestly because it will it easier to drop a column you've just added but maybe mispelled the name until CASSANDRA-3919. Once CASSANDRA-3919 is in, I'm not sure this will be so useful anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira